应用架构反馈答案

【问题标题】：Application Architecture Feedback应用架构反馈
【发布时间】：2010-10-18 08:44:27
【问题描述】：

我正在寻找有关当前设计的反馈。

这是它目前的样子

Web 应用 (UI) 参考 BLL 层和 BusinessEntities 层
BusinessEntites 层 - 包含接口和类（对属性进行内部验证）
BLL（引用 BusinessEntities 和 DAL 层）- 使用 Create() Save() Delete() 等方法主要为每个业务对象提供管理器。
DAL（引用 BusinessEntities 层）- 具有创建/添加/更新业务实体对象的 DB 命令。

我不太确定我用于图层的命名约定，所以如果有人有更好的建议，我很乐意采纳。

我也不喜欢 DAL 引用 BusinessEntities 层的想法，但我还能如何返回对象而不是 Datasets/DataTables？

感谢您的任何反馈。

【问题讨论】：

【解决方案1】：

关于您需要从 DAL 引用业务层，我同意这可能不是最优的——较低层不应该知道它们上面的那些，它降低了可重用性并增加了额外/潜在的循环依赖。

您是否考虑过让您的业务实体“充实自己”并使用 DAL 类执行自己的持久性操作，而不是让 DAL 充当它们的工厂（如在您当前的设计中）？这样，您的 DAL 将是数据库的更直接表示，并且业务实体将包含适当填充和持久化自身所需的（业务）逻辑。

另外，您指定的“BLL”层在我看来并不真正包含业务逻辑；在我看来，它更像是实体的持久服务层。

所以你建议的变化可能是：

根据您的要求，我会考虑将您的 BusinessEntities 和 DataServices（原始设计中的 BLL）合并到一个层中；我能想到将它们分开的唯一原因是，如果您正在做类似 Silverlight 的事情，您需要对客户端业务实体进行异步数据操作。

当然，所有这一切都是在您不完全了解您的特定系统要求的情况下进行的——您需要设计最适合您的特定应用的方案。祝你好运！

【讨论】：

谢谢你。我仍然很难理解 DAL 如何在不知道任何内容的情况下将一个类传回 DataServices 层。我显然对此很陌生，所以也许举个例子会有所帮助。如果你当然有时间，但如果没有也没关系。
我看到你问了一个后续问题，但简单回答一下，我将在 DAL 中定义 DTO，如果我需要数据访问服务层，我会将其接口暴露给 BusinessEntities消息合约，独立于 DTO。 DTO 只是让您避免传递 ADO.NET 对象。
那么它会不会像下面这样：DAL 有 IAddressDTO、一个 AddressDTO 和公共 IAddressDTO GetAddress(int id){}。然后数据服务层将有一个方法 public Address GetAddress(int id) { DAL.IAddressDTO iadd = new DAL.AddressDAL.GetAddress(int id); // 使用 DTO 创建地址对象 }
当然。您还可以在可以在所有层中引用的“通用”程序集中定义您的 DTO，以便它们可用于每个层并可以在它们之间传递。