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

Question

我的团队正在讨论我们参与项目的未来方向。一半的团队相信纯粹的三层架构，而另一半则支持双层架构。

项目假设：

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

3层小组喜欢：

1. 持久层< ==>域层< ==> UI层
2. 服务至少持续性层之间的边界和领域层。域层可能之间有服务边界。
3. 每层之间的转换（清洁DTO分离）
4. 手卷持久性，除非我们能找到创意又不失优雅自动化

2层小组喜欢：

1. 实体框架+ WCF数据服务层< ==> UI层
2. 保留在WCF数据服务拦截器中的业务逻辑
3. 层之间最小的翻译 - 有利于更快的编码

所以这是高层次的论点。我们应该考虑哪些考虑因素？两种方法都有哪些经验？

Answer 1

有时间和地点进行前期设计，只有经验丰富的建筑师才能知道项目的来龙去脉。对于我来说，如果有充分的任何疑问，或者它可能会有两种方式，我把它像这样：

1. 启动小（一层）
2. 使用界面驱动的开发&好SRP，敏捷设计，等
3. 一旦你有一个工作原型，有一个重新设计会议。选择应该更清楚。

YMMV。

Answer 2

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

然而，我认为这应该是关于事情的优先事项清单要低得多。分层的方法本身并不会帮助你。这是如何构建那些重要的层。我觉得让每个人都认同编码实践是非常重要的。像依赖注入，关注分离，控制反转，单元测试，嘲讽等等。这些事情比关注有多少层次更重要。一旦这些步骤到位，层级将自然遵循。