BLL与DAL之间的通信

Question

解决方案设置：

• DAL (类库)
• (类库)
• 公共(类库(一些常见功能-枚举、日志记录、异常、.))
• Application1 (Windows )
• Application2 (Windows )
• WebApp (网络应用程序)
• ..。

假设我有一个Customer实体，即：

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

BLL和DAL应该使用什么类型的对象进行通信-- DataTable或List<Customer> (例如)？在第一种情况下，BLL逻辑应该将Customer对象转换为DataTable，并将其发送给DAL。在安全情况下，DAL层应该知道客户类，这是在BLL层。但原始DLL引用DAL而不是相反..。

我是否应该将所有类放入独立的程序集中，这是所有其他类所引用的(公共、BusinessObjects、.)？在这种情况下，我可以在我的所有项目中使用Customer类。

当我知道时，如果我费心把DAL和BLL分开的话，那么只有一个BLL会使用我的DAL。在这种情况下，我可以将它们合并成一个项目。

PS -我正在读关于DataTables的文章，很多人说我们根本不应该使用它们。更好的选择是什么？也许是时候学习一些ORM映射工具了:)

Answer 1

在我看来，您应该有另一个层(分离的dll)。像“域”，你会在哪里保存所有实体，如客户。然后，只需将其包含在层次结构中的所有较高级别(DAL、BLL、UI和其他级别)。

示例体系结构可以如下所示：

(数据库) <-> DAL <-> BL <-> UI

在所有级别上，您都可以访问“域”层。DAL应该返回列表，而不是DataTable。在某个阶段，您可能希望在DAL中使用一些OMR，比如NHibernate，with也会返回一个列表。

Answer 2

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

我以下的想法只是一个建议。你可以自由地考虑它们，改变/忽略你觉得不相关的东西。

将DAL和BLL分开几乎总是一个好主意。数据方案应该对应用程序的其他部分进行封装和隐藏，所以将您的DataTables、DataSets、ORM或任何其他解决方案隐藏在DAL中。BLL (以及上面的层)应该使用简单的数据类型(意思是简单的类)。我认为将这些类放在一个没有引用并且可以在任何地方使用的模型类库中是个好主意。

感觉好像你有太多的layering...do，你真的需要一个客户类在BLL和另一个在应用层？可能是，但我会确定再考虑一下。

根据我最近一个项目的经验(一个每天都有200 K独特访问者的天气网站)，我们使用link2sql进行数据访问(主要是只读数据)，并在我们的ASP.Net MVC应用程序中使用简单的数据类(当然，作为模型/视图模型的一部分)。它运行得相当顺利，我们可以很容易地改变数据方案，而不需要分解其他层。

至于您关于DataTables的最后一个问题，如果您决定使用它们(我会投反对票)，这些对象完全属于您的DAL。它们不应该暴露在其他层中，因为这会创建与特定类的耦合。如果明天小姐能创造一个更好的课程呢？您会切换到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消费者进行对话。这应该会给你足够的去耦。