.net - 我的团队应该如何在 3 层架构和 2 层架构之间做出选择？

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

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

已关闭 1 年前。

Improve this question

我的团队正在讨论我们项目的 future 方向。一半的团队相信纯 3 层架构，而另一半则支持 2 层架构。

项目假设:

1. 企业业务应用
2. 用户之间需要的业务逻辑和数据库
3. 必要的数据验证
4. 面向服务(首选 RESTful 服务)
5. 多年维护计划
6. 支持数百名用户

3 级团队偏好:

1. 持久层<==>领域层<==>UI层
2. 至少持久层和域层之间的服务边界。域层可能之间有服务边界。
3. 每层之间的转换(干净的 DTO 分离)
4. 手卷持久性，除非我们能找到创造性且优雅的自动化

2 级团队偏好:

1. Entity Framework + WCF 数据服务层 <==> UI 层
2. 业务逻辑保存在 WCF 数据服务拦截器中
3. 层之间的转换最少 - 有利于更快的编码

这就是最高级的论点。我们应该考虑哪些因素？您对这两种方法有什么经验？

Answer 1

预先设计有时间和地点，并且只能由了解项目细节的经验丰富的建筑师来完成。对我来说，如果有任何疑问或者可能会发生任何一种情况，我会这样认为:

1. 从小处开始(一层)
2. 使用界面驱动开发、良好的 SRP、敏捷设计等
3. 一旦您有了工作原型(prototype)，就可以进行重新设计。选择应该更加清晰。

YMMV。