Question

我（现在比以往任何时候都更多）看到开发人员编写了大量的图层，例如：



implementation PresentationLayer ->
    interface IMyDTO ->
        implementation MyDTO ->
            interface IMyService -> 
                implementation MyService -> 
                    interface IMyDomainRepository ->
                        implementation MyDomainRepository ->
                            interface IMyDomainObject -> 
                                implementation MyDomainObject ->
                                    interface IMyIndependentStorageLayer ->
                                        implementation MyMSSQLStorageLayer

implementation PresentationLayer -> interface IMyDTO -> implementation MyDTO -> interface IMyService -> implementation MyService -> interface IMyDomainRepository -> implementation MyDomainRepository -> interface IMyDomainObject -> implementation MyDomainObject -> interface IMyIndependentStorageLayer -> implementation MyMSSQLStorageLayer

通过C＃博客，这似乎是切片面包以来最好的事情。基本上，一切都松散耦合。不要直接使用域对象。通过服务层运行所有内容。通过存储库访问数据。所有图层都完全独立。

不要误会我的意思，我喜欢这个想法，但不是时间的折衷，特别是在一个更大的项目上？维护的投资回报率是否足以证明这一点？

我读到的解释有点尴尬，例如“如果需要，我可以附加不同的数据库”。真？我不认为这是一个常见的问题，有人突然要求从MSSQL切换到Oracle，现在你坐在那里，希望你有一百万个层，彼此都不知道。

是否存在松散耦合过度的趋势，或者我只是在阅读错误的博客？你觉得这个怎么样，并且你有一些事情，你以后真的很高兴你在开始时做了额外的工作？

Answer 1

显然，它可能过头了，需要知道“在哪里停止”添加图层。

我的经验法则是，如果一个图层不需要包含任何重要的功能/代码，我就不需要它。话虽如此，可测试性是一个重要的事情，所以如果一个层给我带来更好的可测试性，我会添加它。

Answer 2

应用程序设计中没有任何东西没有价格。这里的价格增加了复杂性。在选择最符合您需求的选项之前，您始终需要查看选项。

话虽如此，我认为你的问题听起来有些偏颇。在现实世界中，您可能不会经常看到客户要求新类型的数据库，但您可能经常会看到一个新的客户需要与之前相同的数据访问，而在另一个数据库上。它不仅仅是易于改变，而且还与代码重用有关。

Answer 3

为软件设计正确的业务一致概念非常困难。我的意思是可接受的投资回报率。

然而，对我来说，软件概念的层数或低耦合程度取决于软件的使用环境！

如果您确定该软件必须做什么，并且将来可能没有大的修改或增加，那么具有大量层的超低级耦合应用程序不是解决方案。因为它使架构过于复杂而没有任何理由，并且为架构投入的时间不利于...... 另一方面，如果您知道应用程序必须为每个客户定制，并且肯定会进行深度修改，那么花在低级耦合架构上的时间是个好主意...
当您想要将部分代码重用于其他应用程序时，低级别耦合可以是智能的。在这种情况下，设计的时间花费当然是完全有利可图的然后，总而言之，我将说明所有这些都取决于未来软件的发展以及代码重用对其他应用程序的潜在影响。
但对我来说，这不是一个系统非常复杂的架构的最佳实践。

Answer 4

在评估这些内容时，我通常会发现通过DRY原则的镜头来看待它并查看项目中的重复是有帮助的。

如果您使用的体系结构比项目更复杂，那么除了包装其他图层并传递调用之外，您还会看到很多图层几乎没有。这是在重复自己。

另一方面，如果您在复杂系统中使用瘦架构，您可能会发现在系统的某个部分创建功能不会让您在另一个部分重用该功能，迫使您编写很多非常类似的代码到处都是。这是在重复自己。

根据我的经验，如果您在识别重复并不断重构以删除它时保持警惕，结构将呈现给您。比如说你开始使用一个相当基本的架构，但是一旦需要重用它们就把它分解成方法，并且一旦需要被其他类重用就把方法分解成类。然后你可能最终意识到，你为了删除重复而编写的13个Helper / Manager / Handler类实际上看起来有点像他们承担的责任，如果它已进入服务层，可以更明确地定义。< / p>

知道何时值得这样做可能会很棘手，但我认为构建具有大量层次的系统成功的关键在于明确不同层应该具有哪些责任。您添加的任何图层都必须有助于您降低其上方图层中操作的复杂性，并且更容易以优雅的方式将功能组织在一起。

Answer 5

举一个假设的示例项目。测试使用各种进程内SQLite数据库来提高速度，某些开发人员计算机上的开发数据库是PostgreSQL，登台数据库是单个Oracle安装，生产数据库是一个可大规模扩展，非常昂贵，并且很难配置Oracle群集。

如果不将SQL层与业务层分开，您将如何实现这一目标？

Answer 6

这是最近的趋势，经验不足的领导者/建筑师正在成为赶时髦的潮流的牺牲品。

在我正在进行的项目中，数据访问进行了：

服务接口 - ＆gt;服务实施 - ＆gt;代表接口 - ＆gt;代表实施 - ＆gt; DAO接口 - ＆gt; DAO实施 - ＆gt; Ibatis XML。

在我们的案例中这是（并且是！）不好，因为任何委托实现方法中的大多数代码都是单行;它只是叫做DAO。对于每个DAO，我们有两个额外的类和一个额外的bean配置，我们根本没有获得任何东西。

接受更改，重构并继续前进。使用尽可能多的层来分割不同的概念......然后停止。如果编写一些代码除了它将遵循模板之外没有任何明显的好处，要么放慢速度并尝试完全理解模板为什么这样做，要么接受模板对于您的应用程序是错误的并忽略该位。

Answer 7

我目前正在开发一个大型SOA项目，其中每个层都是分离的，几乎每个类都通过一些抽象工厂实例化。现在我们试图将一些现有功能卸载到单独托管的服务中，并且这是一个真正的噩梦，通过层试图推断重要位，因为有一个永无止境的右键单击＆gt;转到定义...来追逐最外层的一行代码！

解耦本身没有任何问题，当然，即使在我的项目中，从架构的角度来看，我发现它有很多领域是有用的。只是不要忘记......务实，并在检查你正在考虑去耦的区域时权衡利弊。

干杯

保持一切松散耦合和可扩展：太多层，ROI太小？

7 个答案: