多少层太多？
过去两年我学习软件开发的知识越多，似乎遇到的灰色地带就越多。我现在遇到的一个灰色区域是尝试确定应用程序应该有多少层。例如，在 WPF MVVM 应用程序中，哪种分层方式合适？以下是不是太分开了？当我提到分层时，我的意思是为每一层创建一个新的类库。
- 表示（视图）
- 视图模型
- 业务层
- 数据访问
- 模型层
- 实用层
或者对于非 MVVM 应用程序来说这是否太分离了？
- 表示
- 业务
- 数据访问
- 模型层
- 实用程序层
一起运行层并为每个层创建文件夹是否可以接受？该灰色区域的任何颜色都将受到赞赏。
As I have been learning about software development the last 2 years the more I learn, it seems the more gray areas I am running into. One gray area I have issues with right now is trying to decide how many layers an application should have. For example, in a WPF MVVM application what fashion of layering is ok? Is the following too separated? When I mention layering I mean creating a new class library for each layer.
- Presentation (View)
- View Model
- Business Layer
- Data Access
- Model Layer
- Utility Layer
Or for a non MVVM application is this too separated?
- Presenation
- Business
- Data Access
- Model Layer
- Utility Layer
Is acceptable to run layers together and just create folders for each layer? Any coloring of this gray area would be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
答案是，这取决于情况。首先，单独的类库并不总是意味着单独的“层”。层是相关功能的概念分组，它可能会也可能不会在单个程序集中体现出来。
您创建多少层实际上取决于您当前的问题。传统上，WPF MVVM 应用程序将至少包含 3 层（模型、视图、视图模型），但它确实可以变化。我经常看到视图和视图模型在同一个程序集中，而模型在它们自己的程序集中（通常是因为模型对象是在其他上下文中使用的 POCO）。
实际上没有什么灵丹妙药可以回答您的问题，它完全取决于你的问题。 “分层”和分离的优点是提高可维护性，促进代码重用，并提高整体清晰度（仅举几例）。
我认为，如果您当前的分层解决方案没有达到这些目标，那么您还有改进的空间。如果增加层数会降低清晰度或可维护性，那么您就走得太远了。如果您只有一个“层”并且它变得臃肿，那么您有机会添加一个层。
最重要的是，不要为了遵循严格的“模式”而过度设计某些东西。如果该模式对您和您手头的问题有明显的优势，那么就实施它，但要理解为什么要这样做以及每个“层”的目标是什么。
The answer is, it depends. First off, a separate class library doesn't always mean a separate "layer." A layer is a conceptual grouping of related functionality, that may or may not manifest itself in a single assembly.
How many layers you create is really dependent on your problem at hand. Traditionally, a WPF MVVM application will contain at least the 3 layers (Model, View, View Model) but it can really be varied. Often times I see the Views and ViewModels in the same assembly and the models in their own assembly (usually because the Model objects are POCO's that are used in other contexts)
There is really no silver bullet that answers your question, it is entirely dependent on your problem. The advantage of "layering" and separation is to increase maintainability, promote code re-use, and increase overall clarity (to name a few).
I would argue that if you are not reaching these goals with your current layering solution then you have room to improve. If increasing the layers is decreasing the clarity or maintainability then you have gone too far. If you have only a single "layer" and it is becoming bloated then you have an opportunity to add a layer.
The bottom line is don't over engineer something for the sake of following a strict "pattern." If the pattern has clear advantages to you and your problem at hand then implement it, but understand why you are doing so and what the goal of each "layer" is.
考虑以下方面：
...然后根据您看重的内容调整您的架构。我可能遗漏了一些其他重要的部分，但你明白了。这个问题确实没有正确或错误的答案。
Consider the following areas:
...then adjust your architecture based on which of these you value. I'm probably missing some other important parts, but you get the idea. There's really no right or wrong answer to this.
如果层本身成为项目可维护性的障碍而不是提高可维护性，那么应用程序的层就会过多。
An application only has too many layers if the layers themselves become a hurdle to the maintainability of the project as opposed to improving maintainability.
过多的确切层数比所需层数多 1 层。
The exact number of layers that is too many is 1 more than is needed.
分层架构：< /strong> 本文介绍了 .NET/WPF 富客户端应用程序的具体示例架构。此外，该架构还显示您在哪一层找到模型-视图-视图模型 (MVVM) 模式的参与者。
Layered Architecture: This article describes a concrete example architecture for .NET/WPF Rich Client Applications. Furthermore, the architecture shows in which layer you find the participants of the Model-View-ViewModel (MVVM) pattern.