6

我正在从头开始开发一个小型应用程序，并使用它来尝试自学架构和设计概念。这是一个 .NET 3.5、WPF 应用程序，我使用 Sql Compact Edition 作为我的数据存储。

我正在研究业务逻辑层，并且刚刚开始编写 DAL。我只是使用 SqlCeComamnds 来发送简单的查询，并使用 SqlCeResultSet 来获取结果。我开始设计我的插入和更新方法，这就是问题所在 - 我不知道将必要数据从 BLL 获取到 DAL 的最佳方法。我是否传递了一个通用集合？我是否有一个包含数据库所有数据的海量参数列表？我是否只是传入实际的业务对象（从而将我的 DAL 与 BLL 中的具体内容联系起来？）。

我考虑过使用接口 - 只需将 IBusinessObjectA 传递到 DAL，这提供了我正在寻找的简单性，而不会将我与当前实现过于紧密地联系在一起。你们有什么感想？

4

4 回答 4

5

我认为您的问题没有简单的答案，因为根据情况有很多选择。我发现阅读以下两本书有助于我更好地理解您描述的问题。

  • MS .NET：为企业构建应用程序（Esposito，Saltarello）
  • MS 应用程序架构指南，第 2 版。

第二本书可在线获取。看这里。

于 2010-04-24T17:15:22.803 回答
3

我认为将业务对象传递给数据访问层是可以的。我认为 BLL 的工作只是处理它的对象，检查是否遵循了所有规则，关于可以保存什么，由谁，在哪些领域，时间等。

一旦它完成了它应该将它传递给 DAL，我认为它的工作是弄清楚如何将它得到的东西转换成可以持久化的东西，但它不会检查持久化或读取的内容或由谁，它会做到的。这可能是直接的，la linq，但如果您的逻辑 mdoels 与您的数据模型 1:1 不匹配，那么 DAL 应该进行所有转换。

关于将你的 DAL 绑定到 BLL 中的东西，我认为你应该担心反过来，将你的 BLL 绑定到你的 DAL。我将使用一个接口来表示您的 DAL（如在 IRepository 中），这样您就可以通过更改它正在使用的 IRepository 的类型来使您的 BLL 调用任何类型的持久性机制（如果您使用 IoC 则加分：P）。实现 IRepository 的具体类将与业务对象相关联，但他们必须知道他们保存的是什么，不是吗？而 BLL 不必知道是什么在进行储蓄。

于 2010-04-24T17:12:10.513 回答
3

在 DAL 中传递业务对象是最简单和最快的方法。它适用于小型项目，但具有相同的缺点：

1）业务对象是 BLL 层的一部分，如果您在 BLL 中传递对象，则 DAL 将依赖于 BLL。低层知道上层——这与层的想法完全矛盾。

2）业务对象直接保存在BD中通常非常复杂。在这种情况下，最好引入新的“映射器”中间层。

为了克服所有这些问题，我通常使 DAL 的接口独立于业务对象。我改用“行”类 - 表示数据库或 XML 中的一条记录。在 .NET 3.5 中，linqtosql 自动生成的类可用于此目的。

于 2010-04-24T17:19:50.490 回答
2

如果我处于你的位置，我可能会使用 LINQ to SQL 来定义我的数据访问层 - 它会为你节省大量维护所有 SqlCeFooBar 东西的工作，并为你提供一个设计器来维护你的数据库否则会缺少，使用 SQL CE。

因此，在这种情况下，我可能会将业务逻辑层与 L2S 层公开的实体紧密耦合。理由是实体是业务对象，尽管没有任何服务。

不过，我可能不会让实体在层次结构中达到 UI 的高度。在那个级别上，使用专门用于视图的模型更有意义 - 特别是考虑到您正在使用 WPF。

当然，所有这些都取决于应用程序的大小和复杂性。鉴于您使用的是 SQL CE，我假设它是一个相当小规模的应用程序（单个用户？）。

于 2010-04-24T17:24:41.903 回答