Asp.net DAL和BLL首选设计模式方法

我正在开发一些小型ASP.NET应用程序，并想知道什么模式。你在项目中使用的方法。Asp.net DAL和BLL首选设计模式方法

我的项目涉及使用数据访问和业务逻辑层的数据库。

，我用至今的数据访问方法如下（我在一些书上看到，喜欢它）：

对于DAL层：
创建一个抽象类，将确定所有数据库操纵方法来执行。抽象类将包含一个静态“Instance”属性，它将加载（如果实例== null）所需类型（实现它的类）的实例（Activator.CreateInstance）。

创建一个实现这个抽象类的类，实现将根据使用的数据库（SQL，mySQL等）。
有了这个我可以根据使用的数据库创建不同的实现。

对于BLL层：
封装所有所有检索到的字段和静态方法，将调用DAL类的类。

这是一个很好的方法吗？
你喜欢在这些情况下使用什么？

来源

2010-03-03 luppi

通过使用静态类方法，您隐藏了对这些组件的依赖关系，并在将来限制您的选项（例如，您不能继承业务层）。

而不是使用单件和静态方法为数据访问层和业务层，考虑改变你的业务层类需要一个数据访问情况，并保持业务层的单个实例在您的顶级应用程序：

public class Global HttpApplication { 

    // This would really be a property 
    // It's also unfortunate this has to be static, but you're stuck with 
    // default constructors for ASP.NET pages, so there's no alternative. 
    public static BusinessLayerClass BusinessLayer; 

    protected void Application_Start(object sender, EventArgs e) { 
     AbstractDataAccessLayer dataAccess = new ConcreteDataAccessLayer(); 
     Global.BusinessLayer = new BusinessLayerClass(dataAccess);    
    } 
}

页面，然后使用它是这样的：

public void PerformSomeBusinessFunction() { 
    Global.BusinessLayer.DoSomething(); 
}

这使得很明显，业务层需要的数据访问，提供了一个方便的地方指定将使用哪种类型的数据访问对象，并铺平了道路FO如果必要，你可以使用不同的创建策略。例如，您可能会提供数据访问工厂，而不是在所有业务层中共享单个实例。

这里的一般原理被称为“dependency injection”（有时它被称为“控制反转”，这是背后DI偶数更普遍的原则。）

如果dependency injection by hand开始变得繁琐，考虑使用a dependency injection framework（人们也称这些“IoC容器”）。

来源

2010-03-03 17:43:29

你是什么意思顶级应用程序？ – luppi

我可能应该说'申请'。在.NET中，这是您的可执行文件或'HttpApplication'类（'Global'）。 –

如果我为每个模块定义DAL和BLL层，该怎么办？可以说我有3个模块：用户，评论，BlogPosts他们每个人都会有它自己的DAL和BLL类（当然每个人都可以使用不同的数据库提供者），这将需要我在global.aspx中定义许多属性。它有效吗？ – luppi

嗯，我会告诉你关于你的方法的一些缺陷，以及我通常如何做。

陷阱

您DAL实例属性似乎是在做一个单身的智能，奇怪的方式。你应该记住，对你的web服务器的请求可以异步处理，所以如果你的Activator.CreateInstance调用需要一些时间，这可能会导致一些问题。

我猜，你的BLL层有同样的问题。最好对应用程序启动事件进行这种初始化（不记得确切的名称）。

你基本上在这里使用的是DI原则和存储库模式。两者都很好，并且可以进行修改和测试，但是，由于您的抽象类将在DAL中，并且您的BLL方法将调用DAL类，因此BLL需要了解DAL。这可能是一个问题。您可以创建一个中间库，并为您的抽象类提供一个接口。

我通常做

我真的不喜欢在一个应用程序“层”，因为它往往很难不同类型的功能进行区分，并且在哪个方向，他们应该知道其他层。我使用了另一种方法，我不太确定是否配了任何东西，但我把它称为依赖圆:)基本上，它就像一个飞镖板，最内层的组件对最外层的组件不知道。

在您典型的博客引擎web应用程序，我会做这样的事情：

BlogEngine.Core持有各种项目（Post，User，Comment，等等）以及各种接口服务的POCO实体。这些服务可以包括IEmailService,IBlogRepository,IUserManagement等等......我现在做一个BlogEngine.Infrastructure.Persistence程序集，它知道.Core并实现了IBlogRepository。我对所有其他服务也一样。
现在 - 您的BlogEngine.Web只需引用您的.Core程序集和IoC框架程序集，该程序集将处理所有依赖关系。如果我想更新帖子，我可以做myIOC.GetInstance<IBlogRepository>().SaveOrUpdatePost(newPost);。
比方说，当人们在他们的博客上发表评论时，你想通知作者。您可以在.Core中以Notifier-类的形式实现此逻辑。这个类可以解析IEmailService，然后发送你需要的任何邮件。

要点：你有一个核心，它永远不会改变你的域名。然后你得到只知道Core的基础设施组件。你有你的知道关于Core和IOC框架的Web应用程序 - 并且你得到了你的IOC，它知道所有事情，并且被允许这样做:)如果你需要进行修改，很可能是它在基础结构程序集中，所以你只需要更新您的IOC的设置和实施其

我希望这是有道理的，如果没有，请发表评论和生病尝试进一步解释:)

好运

来源

2010-03-03 16:31:26 cwap

这是什么IoC架构？ – luppi

http://martinfowler.com/articles/injection.html –

这是一个好的方法。我也使用这种方法。我使用DAL的企业库。最近我发现使用L2S对于DAL很有用。

我也推荐使用NHibernate。

来源

2010-03-03 16:38:21

Asp.net DAL和BLL首选设计模式方法

回答

相关问题