题

解决方案设置：

  • DAL（班级库）
  • BLL（班级库）
  • 常见（类库（一些常见功能 - 枚举，记录，异常，...））
  • Application1（Windows应用程序）
  • Application2（Windows应用程序）
  • WebApp（Web应用程序）
  • ...

假设我有一个 顾客 实体，这是：

  • SQL Server中的表格
  • DAL中的客户参与
  • BLL的客户课程
  • 所有应用程序中的Bll.customer类

什么样的对象应BLL和DAL用于通信 - DataTable 或者 List<Customer> （例如）？在第一种情况下，BLL逻辑应将客户对象转换为DataTable并将其发送到DAL。在SECOD案例中，DAL层应了解BLL层的客户类。但是原始的dll参考dal而不是相反...

我应该将所有课程都放入分开的集会中，所有其他类别都被所有其他类别所引用（常见的业务对象，...）？在这种情况下，我可以在所有项目中使用客户类。

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

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

有帮助吗？

解决方案

我认为您应该有另一层（单独的DLL）。像“域”一样，您将在哪里保留所有实体，例如客户。然后，只需将所有较高级别（DAL，BLL，UI和其他）包含在此组件的层次结构中即可。

示例体系结构看起来像这样：

（数据库）<-> dal <-> bl <-> ui

在所有级别上，您都可以访问“域”层。 DAL应返回列表，而不是数据表。在某个阶段，您可能想在DAL中使用某些OMR，例如Nhibernate，也可能会返回列表。

其他提示

很难在不了足够好了解应用程序领域的情况下回答这个普遍的问题。我将首先考虑将来最有可能发生的变化，并尝试从需要灵活性的地方找出。

我的以下想法只是一个建议。随意考虑它们，改变/忽略您的感觉无关紧要。

将DAL与BLL分开几乎总是一个好主意。数据方案是应封装并隐藏在应用程序的其余部分中的一件事，因此请将数据集，数据集，ORM或隐藏在DAL中的任何其他解决方案。 BLL（以及上面的层）应使用简单的数据类型（意味着简单类）。我认为将这些课程放入没有参考的模型类库中是个好主意，可以在任何地方使用。

感觉您有太多的分层...您真的需要BLL中的客户类，而在应用程序层中的另一个？可能是，但我会确保并认为这两次。

从我最近的一个项目之一（每天有200k唯一访问者的天气网站）中，我们使用link2sql进行数据访问（大多数仅读取数据），以及我们的ASP.NET MVC应用程序中的简单数据类（当然为模型/视图模型的一部分）。它运行得非常顺利，我们可以轻松地更改数据方案而不会分解其他层。

至于您关于数据词的最后一个问题，这些对象，如果您决定使用它们（我会投票反对），仅属于您的DAL。它们不应暴露于其他层，因为这会与该特定类创建耦合。如果明天女士发明了更好的课程怎么办？您现在可以切换，因为您的项目上都有售价数十亿个参考，其方法和属性？只需更改您的DAL即可与Newawsomatatabable类合作，您的应用程序的其余部分非常无知。

希望有帮助:)

我将使用以下模式，因为它允许您以后升级到其他持久性策略。

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

在这里，视图模型在BLL之外消耗，并且模型在BLL/DAL层上进行了传达。

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

关于将类型保存在自己的组件中 - 是的，对于视图模型而言，为了保持一致性，对于模型而言。

保持模型和视图模型将持久性策略泄漏在BLL之外的泄漏，从而允许未来的设计改变持久性。

这种分离的优点是，不同的视图模型消费者可以为同一持久性模型/实体具有不同的视图模型。有些可能很小，几乎没有属性，而有些属性很大，功能丰富。它还允许您引入离线/断开性功能，因为可以在不同的时间返回视图模型，从而确定数据合并策略。这也允许您持久实体（例如表格生长和改变形状）。由于这看起来像是.NET实现 汽车应用程序 开箱即用的功能

当然，对于您的应用程序来说，这可能是过分的 - 但是，我仍然保留一个BLL映射，仅将查看模型与所有BLL消费者交谈。这应该给您足够的脱钩。

将域实体推入DAL是可以消除crcular依赖性的选项，但可能不符合您的意图。但是，这并不是闻所未闻的。例如，linq to-sql gnerated实体将生活在DAL中。

其他选项：

  • 将它们放在一个共同的地方 降低 组装（但这可能会使您的BL相当空）
  • 使用IOC删除 /反向BL / DAL之间的参考

这里没有正确的答案。

re dataTable;我个人同意 - 我不是粉丝;）但是，它们可以成功合理地使用它们。但是如果我 有 要使用它们，我会将它们保留在DAL中作为实施细节 - 并且不要将它们暴露在上面。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top