我的团队应该如何决定3层和2层架构？

Question

我的团队正在讨论我们开展项目的未来方向。一半的团队相信纯粹的3层架构，而另一半则倾向于采用双层架构。

项目假设：

1. 企业业务应用程序
2. 用户之间需要的业务逻辑 和数据库
3. 必要的数据验证
4. 面向服务（更喜欢RESTful服务）
5. 多年维护计划
6. 支持数百名用户

三层团队优惠：

1. 持久层＆lt; ==＆gt;域层＆lt; ==＆gt; UI图层
2. 至少持久层和域层之间的服务边界。域层可能之间有服务边界。
3. 每层之间的翻译（清洁DTO分离）
4. 手持滚动持续，除非我们能找到创意而优雅的自动化

2层团队优惠：

1. 实体框架+ WCF数据服务层＆lt; ==＆gt; UI图层
2. 业务逻辑保留在WCF数据服务拦截器中
3. 层之间的最小转换 - 有利于更快的编码

这就是高级别的论点。我们应该考虑哪些因素？你有什么经验吗？

Answer 1

前期设计有时间和地点，只有经验丰富的建筑师才能知道项目的细节。对我来说，如果有任何疑问，或者它是否可以采取任何一种方式，我会这样理解：

1. 从小（一层）开始
2. 使用界面驱动的开发＆amp;良好的SRP，敏捷设计等
3. 拥有工作原型后，进行重新设计会话。选择应该更清楚。

因人而异。

Answer 2

我不相信双方实际上相距甚远。对我来说听起来像2层方法更关注于演示，并希望服务能够完成繁重的工作。这些服务仍然可能有另一层涉及数据访问，因此它是另一种3层方法。它也是我们在工作中所青睐的，因为假设我们保持相同的界面，经常对服务进行更改并不需要对消费者进行任何更改。

然而，所有这一切，我认为这应该在要关注的事项的优先列表上低得多。分层方法本身并不会对您有所帮助。这些层级的构建方式非常重要。我觉得每个人都同意编码实践更为重要。诸如依赖注入，关注点分离，控制反转，单元测试，模拟等等。这些事情比关心层数更重要。一旦这些层落到位，层级将自然地跟随。