当我学习软件开发时，最近两年我学到的越多，看起来我遇到的灰色地带就越多。我现在遇到的一个灰色区域是试图确定应用程序应该具有多少层。例如，在WPF MVVM应用程序中，什么样的分层方式可以？以下是否分离？当我提到分层时，我的意思是为每个图层创建一个新的类库。有多少层太多？
或者用于非MVVM应用程序是这样的太分开吗？
是可以接受的运行层一起，只为每一个图层文件夹？任何这个灰色地区的着色将不胜感激。
Layered Architecture:本文介绍.NET/WPF富客户机应用程序的具体示例体系结构。此外，该体系结构显示您在哪一层找到Model-View-ViewModel（MVVM）模式的参与者。
答案是，这取决于。首先，单独的类库并不总是意味着单独的“图层”。一个图层是相关功能的概念分组，可能会或可能不会在单个程序集中表现出来。
您创建的图层数量真的取决于您的问题。传统上，WPF MVVM应用程序将至少包含3层（模型，视图，视图模型），但它可以真正变化。很多时候，我会在同一个装配体中看到Views和ViewModel，并在自己的装配体中看到模型（通常是因为Model对象是在其他环境中使用的POCO）
真的没有银弹可以回答你的问题，完全取决于你的问题。 “分层”和分离的优点是增加可维护性，促进代码重用，并提高总体清晰度（仅举几例）。
我会争辩说，如果你没有达到目前的分层解决方案的这些目标，那么你有改进的空间。如果增加层是减少的清晰度或可维护性，那么你已经太过分了。如果你只有一个“层”，并且它变得臃肿，那么你有机会添加一个图层。
为了遵循严格的“模式”，底线是不要过度设计某些东西。如果模式对您和您手边的问题有明显的优势，然后实施它，但要明白为什么要这么做，以及每个“层”的目标是什么。
考虑以下几个方面：
...然后在此基础上的这些你重视调整结构。我可能错过了一些其他重要的部分，但你明白了。这确实没有正确或错误的答案。
如果应用程序本身成为项目可维护性的障碍而不是提高可维护性，那么应用程序的层数太多。
实际上，我的系统总是包含：'前端代理'任何接受用户请求的东西，比如MVC控制器; 'business'这个处理* sequence *的操作的流程; 'compute'处理所有的算法工作，数据聚合等等。以及处理所有sql调用，远程web请求，文件系统等的“数据访问”。 – 2016-04-06 20:27:08
层数太多的确切层数比需要的多1层。
您可能会问自己的另一个问题是，有多少图层太少？ – 2010-06-07 18:42:44
社区Wiki？对此没有“正确的”答案......灰色地带的情况如何？ :) – 2010-06-07 18:44:03
答案当然是42 – 2010-06-07 18:48:42