design-patterns - 保持一切松散耦合和可扩展: Too many layers,的投资返回率太小？

Closed. This question is opinion-based。它当前不接受答案。

想要改善这个问题吗？更新问题，以便editing this post用事实和引用来回答。

在8个月前关闭。

Improve this question

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

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，这不是一个普遍的问题，现在您坐在那里，希望自己有一百万个彼此都不认识的层。
是否存在松耦合导致过度发展的趋势，还是我只是在阅读错误的博客？您对此有何感想？您是否遇到过一些事例，您后来真的很高兴您在一开始就做了额外的工作？

最佳答案

为软件设计正确的业务定位概念非常困难。我的意思是具有可接受的投资返回率。

但是，对我而言，软件概念的层数或低耦合度取决于使用软件的环境!

如果您确定软件必须执行的操作，并且将来可能不会进行大的修改或添加，那么解决方案就是多层的超低级耦合应用程序不是解决方案。因为这样会使架构变得过于复杂，没有任何理由，并且为架构投入的时间也无法获利...
另一方面，如果您知道必须针对每个客户定制应用程序并且肯定会对其进行深度修改，那么花时间在低级耦合体系结构上是个好主意...
当您想将部分代码重用于其他应用程序时，低级耦合可能很聪明。当然，在这种情况下，花在设计上的时间完全是有利可图的。
然后，总而言之，我将说这一切都取决于 future 软件的发展以及其他应用程序代码重用的潜力。
但这是我最好的做法，即不要系统地构建非常复杂的体系结构。

关于design-patterns - 保持一切松散耦合和可扩展: Too many layers,的投资返回率太小？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1251015/

上一篇：使用资源管理器 View 复制和粘贴时，SharePoint 列表事件接收器未触发

下一篇：javascript - 在 Angular 8 中使用 @viewChild

相关文章：

java - 急切初始化单例 vs 惰性初始化单例

c# - 有类型<>/无类型设计

design-patterns - Builder 模式的真实示例

inheritance - 用于约束和继承集的接口(interface)

java - 实现列表<E> : do I need a new class?

go - 从不同的包golang实现接口(interface)

design-patterns - 享元模式与静态字段

java - 将 JFrame.getText() 从一个类成员传递给另一个类成员？

module - SWI-Prolog 中的跨模块 "interface"调用

c++ - 链表的几种实现——C++