c# - N 层应用程序设计

Question

我对 OOP 中的架构设计相当陌生(我来自编程机器人技术，所以这有点困难)。我所在的团队正在创建一个相当大的应用程序，首席项目经理向我们提出了要求，在这些要求中，我们必须使用图层来创建模块。我们使用的技术是 C# WinForms 和用于数据存储的 Oracle。

我的模块由用户管理组成，我试图将逻辑与实现分开，所以我有以下架构:

• 业务层
• 数据层
• 表现层

我将存储库模式和 IoC 与 EF 一起使用，一切看起来和工作正常，但现在我的老板告诉我，我需要将表示层与数据层完全分开。问题在于我从表示层使用 IoC，如果我想创建一个用户对象，例如我执行以下操作:

_userRepo.InsertNewUser(new User { props here } ); . 

所以这是不正确的，因为我直接访问 DAL。我的老板告诉我，我需要另一个层来隔离这些类型的调用并实现业务规则 (?!)

我在互联网上进行了搜索和研究，但没有找到任何帮助(主要是因为这里的所有内容都在工作中被过滤了)。

我认为我的老板想要某种领域层/服务层，但我不知道如何在当前设计中实现它。我可以毫无问题地发布项目，任何敏感数据都将从代码中删除。

如有任何帮助，我们将不胜感激。

Answer 1

我发布这个作为答案，即使它可能是基于意见的，即使我无法读懂你老板的想法:-)

从根本上说，我认为您的老板想要的是减少所有层之间的依赖性。您选择执行此操作的体系结构模式取决于手头的应用程序。你所描述的看起来像一个 three-tier architecture .让我们简要回顾一下三层架构的样子，以及它应该如何工作:

• 表示层显示信息并作为用户的边界。
• 应用程序层(或业务逻辑)控制应用程序的功能。特别是它处理数据并将其分发到其他层。
• 包含数据访问层 (DAL) 的数据层存储或检索数据。它应该使您的应用程序独立于手头的存储解决方案。它通常适用于数据访问对象 (DAO)。

关于哪个层应该知道其他哪些层，存在不同的思想流派。但从我读到的内容来看，我认为你应该将业务逻辑作为一种中介来提升。这意味着，业务逻辑知道表示层和数据层，但其他层彼此不知道。我尝试通过两个示例场景来阐明这一点:

A.显示现有用户

1. 业务逻辑为特定的 User DAO 请求数据层，例如对应于 id==123 的那个。
2. 数据层返回 User 对象。
3. 业务逻辑读取存储在 User 对象中的值，并相应地在表示层中设置值，例如firstName、lastName 等。它不转发User 本身，仅转发包含的值。

B.创建新用户

1. 表示层收集创建新用户所需的所有值。
2. “提交”时，这些值会到达业务逻辑(例如 IoC)。
3. 业务逻辑告诉数据层使用它从表示层获得的值创建一个新的User 对象。
4. 数据层创建并存储对象。

在不同层之间创建依赖性的是 DAO。 IE。如果您的表示层要实例化一个 User 对象，则它需要导入一个属于 DAL 的类(这不是您老板想要的)。 因此，您可以做的是将表示层和数据层之间的所有通信留给业务逻辑。

作为场景 B 的替代方案，您还可以让业务逻辑创建 User，这样您的 DAL 方法就会变得更简单。

正如我一开始所说，没有一种方法可以做到这一点。如果您需要更具体的信息或有其他问题，请随时提出。