Question

解决方案设置：

DAL（班级图书馆）
BLL（班级图书馆）
Common（类库（一些常用功能 - 枚举，日志记录，异常......））
Application1（Windows应用程序）
Application2（Windows应用程序）
WebApp（Web应用程序）
...

假设我有客户实体，即：

SQL Server中的表
DAL中的CustomerDataTable
BLL中的客户类
所有应用程序中的BLL.Customer类

BLL和DAL应该用什么类型的对象进行通信 - DataTable或List<Customer>（例如）？在第一种情况下，BLL逻辑应将Customer对象转换为DataTable并将其发送到DAL。在secod的情况下，DAL层应该知道Customer层，它位于BLL层中。但原始DLL引用DAL而不是相反...

我是否应该将所有类放入单独的程序集中，所有其他类都引用它（Common，BusinessObjects，...）？在这种情况下，我可以在所有项目中使用Customer类。

当我知道时，我甚至懒得分开DAL和BLL，只有一个BLL会使用我的DAL。在这种情况下，我可以将它们合并到一个项目中。

PS - 我正在阅读有关DataTables的内容，很多人都说我们根本不应该使用它们。有什么更好的选择？也许现在是我学习一些ORM映射工具的时候了：）

Answer 1

在我看来你应该有另一个Layer（单独的dll）。就像“域名”一样，你会在哪里保留像Customer这样的所有实体。然后简单地在此程序集的层次结构中包含所有更高级别（DAL，BLL，UI和其他）。

示例架构可能如下所示：

（数据库）＆lt; - ＆gt; DAL＆lt; - ＆gt; BL＆lt; - ＆gt; UI

在所有级别上，您都可以访问“域”图层。 DAL应该返回List而不是DataTable。在某些阶段，您可能希望在DAL中使用某些OMR（如NHibernate）的开发过程也可能返回List。

Answer 2

如果不充分了解应用程序域，很难回答这个一般性问题。我将首先考虑未来变化的可能性，并尝试从需要灵活性的地方中找出答案。

我的以下想法只是一个建议。随意考虑它们，改变/忽略你认为无关紧要的东西。

将DAL与BLL分开几乎总是一个好主意。数据方案是应该从应用程序的其余部分封装和隐藏的一件事，因此请将您的DataTables，DataSet，ORM或任何其他解决方案隐藏在DAL中。 BLL（及其上面的层）应该使用简单的数据类型（意思是简单的类）。我认为将这些类放在一个没有引用的Model类库中是个好主意，可以在任何地方使用。

感觉你的分层太多了......你真的需要BLL中的Customer类和Application层中的另一个吗？可能会，但我会确保并考虑两次。

根据我最近的一个项目（每天有200,000个独立访问者的天气网站）的经验，我们使用link2sql进行数据访问（主要是只读数据），以及遍布ASP.Net MVC应用程序的简单数据类（当然作为模型/视图模型的一部分）。它工作得非常顺利，我们可以轻松地更改数据方案而不会破坏其他层。

至于你关于DataTables的最后一个问题，这些对象，如果你决定使用它们（我会投反对票），只属于你的DAL。它们不应该暴露给其他层，因为它会产生与特定类的耦合。如果明天MS发明一个更好的课程怎么办？既然你的项目中有大量的参考资料到DataTables，它的方法和属性，你会切换吗？将你的DAL更改为使用NewAwsomeDataTable类更好，而你的应用程序的其余部分是无知的。

希望有所帮助：）

Answer 3

我会使用以下模式，因为它允许您稍后升级到不同的持久性策略。

UI/Consumer  <--- (view models) --> BLL <--- Models ----> DAL/Persistence

此处，视图模型在BLL之外使用，模型在BLL / DAL层之间传递。

在您的情况下，模型可以是DAL使用的任何东西 - 例如DataTables或更高版本的ORM实体。 BLL负责模型和视图模型之间的映射。

关于将类型保存在自己的程序集中 - 对于视图模型是肯定的，为了保持一致性，对于模型也是如此。

保持模型和视图模型的分离可以阻止BLL之外的持久性策略泄漏，从而允许将来的设计更改为持久性。

这种分离的一个优点是，不同的视图模型使用者可以拥有相同持久性模型/实体的不同视图模型。有些可能很小，属性很少，有些很大，功能也很丰富。它还允许您引入脱机/断开连接功能，因为可以在不同时间返回视图模型，从而允许您决定数据合并策略。这也允许你是持久性实体（例如表增长和改变形状）。由于这看起来像.net实现，AutoMapper之类的东西将提供很多开箱即用的功能

当然，这对你的应用程序来说可能有些过分 - 但是我仍然保持一个BLL映射，它只向所有BLL消费者提供视图模型。这应该给你足够的解耦。

Answer 4

将域实体推送到dal是一个可以消除crcular依赖关系的选项，但可能与您的意图不符。然而，这并非闻所未闻;例如，LINQ-to-SQL gnerated实体将存在于DAL中。

其他选择：

将它们放入一个常见的 lower 程序集中（但这可能会让你的BL变空）
使用IOC删除/反转BL / DAL

这里没有单一的正确答案。

Re DataTable;我个人同意 - 我不是粉丝;）但是，它们可以成功且合理地使用。但是如果我有使用它们，我会将它们作为实现细节保存在DAL中 - 而不是将它们暴露在它之上。

BLL和DAL之间的通信

4 个答案: