.net 业务组件：何时介绍它们

我正在执行代码检查（VS2008/.NET3.5）。开发团队在DAC组件中创建了几个数据访问组件

我遇到了一个业务流程程序集，其中每个DAC都用一个业务组件包装，没有附加值或代码

这是一个不成熟的架构步骤吗？只是为即将发生的事情做好准备，比如：缓存、验证或事务？所有这些最后提到的话题现在都不是这样，但将来可能会发生

我在评论中评论说，引入这种架构准备会使代码库膨胀。所以，试着只在真正需要的时候介绍它

---

关于这个问题，您有什么经验？

我的建议是始终拥有业务对象，并始终根据它们编写应用程序。这使得应用层数据访问变得不可知，并从整体上提高了灵活性。这确实需要更多的前期工作，但任何长寿应用程序的红利都是值得的。

这是一个值得称赞的立场。作为架构师，我的第一个错误是在编写一行功能代码之前实现了图表上的所有层。为您的层（在图表上）进行规划是很好的，但它们应该仅在需要时实施

需要时通常是：

• 在物理层上分离逻辑
• 引入逻辑上属于单独层的其他行为
• 为了支持模式而强制执行间接寻址（只要该模式不是对体系结构的自我辩护滥用）

---

也就是说，即使在开始时没有实现层，也需要小心避免层之间的紧密耦合。这样，当您确实需要创建层时，您就不必重写一堆代码。

我同意，拥有一个“空”的业务层似乎有些过分——但我的问题是，如果业务类本质上是DAL类的空包装，那么应用程序中的业务逻辑在哪里被编码？在这些情况下，我经常看到它传播到整个UI和DAL代码和/或数据库/存储过程中，这就破坏了最初拥有业务层的全部目的

---

如果您要有一个业务层，那么它应该尽可能多地封装业务逻辑，包括验证和各种持久性方法。如果你本质上让业务层成为一堆“哑巴”数据传输对象，它就不提供任何价值，你可能应该考虑开发一个没有一个的架构。

嗯，我想现在我不会在评论中对这个话题提出一个大问题。将包装器代码放在BL中可能是明智的。在需要时更容易向其添加一些额外的验证逻辑。