BLL和DAL

Question

解决方案的设置之间的通信：

• DAL（类库）
• BLL（类库）
• 通用（类库（一些常用的功能 - 枚举，日志，异常.. 。））
• 应用1（Windows应用程序）
• 应用2（Windows应用程序）
• Web应用程序（Web应用程序）
• ...

比方说，我有一个客户实体，它是：

• 在SQL服务器
• 一个CustomerDataTable在DAL
• 一个Customer类BLL表
• a BLL.Customer class in all the applications

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

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

当我知道时，我应该甚至打扰分离DAL和BLL，只有一个BLL会使用我的DAL。在这种情况下，我可以将它们合并为一个项目。

PS - 我正在阅读有关数据表，很多人说，我们不应该使用它们。什么是更好的选择？也许是时候让我学习一些ORM映射工具:)

Answer 1

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

采样架构可以是这样的：

（数据库）< - > DAL < - > BL < - > UI

，并在各个层面，你将有机会获得 “域” 层。 DAL应该返回List而不是DataTable。在某些阶段，您可能希望在DAL中使用像NHibernate一样的OMR开发流程，也可能会返回一个List。

Answer 2

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

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

这里，视图模型在BLL之外消耗，模型在BLL/DAL层之间通信。

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

至于保留类型在他们自己的程序集 - 是视图模型，并为了保持一致性，对于模型也是。

保持模型和视图模型单独停止BLL之外的持久性策略泄漏，从而允许将来的设计更改为持久性。

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

当然，这可能是对你的应用程序的矫枉过正 - 但我仍然保持一个BLL映射，只谈论视图模型给所有BLL消费者。这应该给你足够的解耦。

Answer 3

将领域实体推入dal是一个选项，可以删除crcular依赖项，但可能与您的意图不符。但这并不是闻所未闻的;例如LINQ到SQL的实体会存在于DAL中。

其他选项：

• 把它们放到一个共同的下组件（但可能会留下您的BL而空）
• 使用IOC删除/反向BL/DAL之间的参考

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

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

Answer 4

很难回答这个普遍问题，而不知道应用程序域是否足够好。 我会先考虑未来变化的最可能发生地点，并试图从需要灵活性的地方找出答案。

我以下的想法只是一个建议。随时考虑他们，改变/忽略你觉得无关紧要的事情。

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

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

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

至于你最后一个关于DataTables的问题，这些对象，如果你决定使用它们（我会投反对票），只属于你的DAL。他们不应该暴露于其他层，因为这会创建耦合到特定的类。如果明天MS发明更好的课程怎么办？你现在是否可以切换到你的项目中有大量的引用到DataTables，它的方法和属性？如果将DAL更改为NewAwsomeDataTable类，并且其他应用程序非常无知，则更好。

希望帮助:)