我正在执行代码审查（VS2008 / .NET 3.5）。开发团队在DAC组件中创建了多个数据访问组件。
我遇到了一个业务流程程序集，其中每个DAC都包含一个没有附加值或代码的业务组件。
这是一个正确的过早架构步骤吗？只是为将要发生的事情做好准备：缓存或验证或交易？所有这些最后提到的主题现在都不是这样，但可能在将来发生。
我在评论中发表评论说，引入这种架构准备工作正在使代码库膨胀。因此，只有在真正需要时才尝试引入它。
您对此问题有什么经验？
答案 0 :(得分：2)
我的投票是始终拥有业务对象，并始终根据它们编写应用程序。这使得应用程序层数据访问不可知，并提高整体灵活性。它确实需要更多的前期工作，但任何长期应用的红利都是值得的。
答案 1 :(得分：1)
表示支持。我作为架构师的第一个错误是在编写一行功能代码之前在我的图上实现所有层。最好为您的图层（在图表上）进行规划，但只应在需要时实施。
需要时通常是：
话虽这么说，即使你没有在开始时实现这些层，你仍然需要小心避免层之间的紧密耦合。这样，当您确实需要创建图层时，您不必重写一堆代码。
答案 2 :(得分：0)
我同意拥有一个“空”业务层似乎有点过分 - 但我的问题是，如果业务类本质上是DAL类的空包装器，那么<em>应用程序中的业务逻辑正在编码？在这些情况下，我经常看到它遍布UI和DAL代码和/或数据库/存储过程，这首先打破了业务层的整个目的。
如果您要拥有业务层，那么它应该尽可能多地封装业务逻辑，包括验证和各种持久性方法。如果你基本上让业务层成为一堆“愚蠢”的数据传输对象，它就没有提供任何价值，你应该考虑在没有它的情况下开发你的架构。