1

我正处于一个新项目的开始阶段。因为，我一直想提高自己并尽量避免过去的错误（每个人都有一些包袱），所以我查看了.NET 的分层架构示例。查看数据和业务逻辑，我发现数据层实际上引用了 ExpenseSample.Business.Entities 程序集，因此数据层知道存在业务层。这看起来和感觉有点尴尬。

当然，它节省了将 DataObject 映射到 BusinessEntities 的时间，但这不是一种“危险”的方法吗？

期待一些讨论，也许还有一些更好的解决方案。

更新：感谢您的输入。我现在用

MyApp.Data.Contracts.*
MyApp.Data.Access.*         /* has the classes to access the DB and maps it to 
                               the Data.Contracts */
MyApp.Business.Entities.*
MyApp.Business.Components.* /* accesses the classes from Data.Access, 
                               maps the Contracts to the Business.Entities and 
                               provides the components to access them */

因此，通过这种方式，我可以确保对数据表示的内部更改不会影响外层。

4

4 回答 4

2

我不同意，所有层都需要访问一些对象，我这样做：

-----------
| DAL | E  |
------- N  |
| BAL | T  |
------- I  |
|  G  | T  |
|  U  | I  |
|  I  | E  |
|     | S  |
-----------

DAL通常连接到一个WCF服务，并且屏蔽了其他知道它的应用程序（所以当WCF过时时它可以在几年内改变）。

BAL 主要特定于应用程序（尽管可以在另一个应用程序中重用），但是实体是专门为应用程序制作的，我不太可能在其他地方使用它们。

当然，这是一个相当小的应用程序，它可以使用其他 dll（模块、第三方等）进行扩展并变得更加复杂，但这就是想法。

我想我想说的是实体和 BAL 是两个不同的东西，不要把它们混为一谈；）

于 2011-11-11T14:58:47.917 回答
1

一般规则是下层不应该了解上层。该示例不正确，因为业务实体是 BAL 而不是 DAL 的一部分。因此业务层应该做映射而不是数据层。

映射并不需要时间，只需使用ValueInjecter 之类的东西

免责声明：我没有看过链接的样本。一般来说，只要给我两分钱关于分层。

于 2011-11-11T14:20:53.160 回答
0

我要说的一件事是，如果您要允许 DAL 访问业务对象，那么您不妨创建一个项目并将 BAL 和 DAL 分离到该项目中的单独目录和命名空间中。至少你不会在分层问题上自欺欺人。

在我从事的大多数项目中，将 BAL 和 DAL 分离到单独的程序集中几乎没有什么好处。如果您的数据库解决方案可能会发生变化，并且您希望自己适应未来，那么请改用像 nHibernate 这样的 ORM。

于 2011-11-11T14:16:51.883 回答
0

...所以数据层知道有业务层

不太正确，它只是知道有一个名为 的命名空间Business.Entities，但这些实体肯定是架构中的叶子。它们不依赖于其他任何东西，只依赖于 .Net 框架。这些实体实际上没有任何逻辑（除了 ToString()），因此它们只是在整个架构中充当数据合约。他们也没有对任何其他项目的引用。唯一不会使它们成为 POCO 的是它们具有序列化意识。

正如狒狒所提到的，这种方法是可能的，我相信有一些例子可以很好地工作。如果你看看这个项目和代码，它看起来都非常漂亮和舒适，我只想爱上它。

只要您仔细计划对整个架构的每一个添加，审查每一个更改并与开发人员密切沟通，这将是美好而有序的。但是，一旦您的架构、数据库和业务流程以更快速的方式发展，您将不得不扩展所有这些层的数据以使用通用对象进行建模。在我看来，有一些例子支持特定于层的数据合约。其中之一是有一天 UI 程序员希望在您的对象中为他的 UI 层添加 PropertyChanged 通知器。哼！你不能这样做而不影响你的 BAL 和 DAL。另一天，您遇到了一种情况，即您希望将仅 GUI 的属性存储在实体中（如显示颜色、屏幕上的位置、选择状态等）。什么' 数据库与它有关吗？如果您仔细观察，您会注意到实体已经具有特定于层的处理。您在导航属性上看到虚拟关键字了吗？它们在那里，以便 EF 可以对它们进行子类化并为您提供启用延迟加载的代理类......这反过来可能并不意味着通过服务传输。

The alternative is to use object mapping (either manual, through templates or by libraries such as AutoMapper). This solution is certainly less clean, less cozy, as there's code duplication, and lines and lines of mapping code. But all that allows you to decouple the data in your layers and model it according to the specific needs for each layer.

于 2011-11-11T18:27:35.867 回答