我是设计模式的新手。我想学习构建3层架构。我搜索过但在某些方面感到困惑。在本文中，http://www.dotnetfunda.com/articles/show/18/4-tier-architecture-in-aspnet-with-csharp编写者添加了另一个名为Business Object tier的层。据我所知，将数据从一个层传输到另一个层是非常有用的。由于此层仅包含业务对象，因此我们可以将此层的引用添加到其他层，这不会破坏规则。
但是其他一些文章，他们正在使用DTO。使用这种方法，我们必须在DAL和BAL之间转换数据。
我认为使用Business对象层更合乎逻辑且更容易，我看不出使用它的任何缺点。
请帮助我找到一个稳定的解决方案。感谢
答案 0 :(得分：1)
因为您在整个应用程序中全局使用业务对象，所以拥有自己的层可以工作。由于业务对象不是特定于实现的，因此它们不应该将您与任何外部依赖项紧密耦合。假设你没有使用像Linq到Sql这样的数据访问技术，其中对象需要特定于Sql的代码。
在过去的几年里，我已经走向了'洋葱建筑'的设计。我将业务对象（实体）和我的接口保存在核心项目中。我将所有业务代码和特定于实现的代码添加到服务项目中，最后添加到标准UI项目中。 UI和服务项目每个都只知道核心。我的所有服务都实现了核心中的一个接口，我的UI代码是针对核心接口编写的，而不是具体的服务实现。通过这种方式，我的UI和我的服务完全分离，彼此不了解。这种模式也可以扩展到包括其他项目（我使用基础设施来解决诸如日志记录等交叉问题）。
但是，对于n层方法，我认为业务对象层很好。您还可以将某种本机数据记录（C＃中的DataTable等）返回到业务层，将对象保留在那里，并包含接受本机数据类型的构造函数。