C# N层应用程序设计

我对OOP中的体系结构设计相当陌生（我来自机器人编程，所以这有点困难）。我参加的团队正在创建一个相当大的应用程序，领先的项目经理向我们介绍了需求，在需求中，我们必须使用层来创建模块。我们使用的技术是用于数据存储的C#WinForms和Oracle

我的模块由用户管理组成，我尝试将逻辑与实现分离，因此我有以下体系结构：

• 业务层
• 数据层
• 表示层

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

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

这是不正确的，因为我直接访问DAL。我的老板告诉我，我需要另一个层来隔离此类呼叫并实施业务规则（？）

我在互联网上搜索和研究，没有发现任何帮助（主要是因为这里的一切都是经过过滤的）

我想我的老板想要一些领域层/服务层的东西，但我不知道如何在当前的设计中实现它。我可以张贴项目没有任何问题，任何敏感数据将从代码中删除

---

任何帮助都将不胜感激。

我将此作为一个答案发布，尽管它可能是基于观点的，即使我无法理解你老板的想法：-）

基本上，我认为你的老板想要的是减少所有层之间的依赖关系。您选择的体系结构模式取决于手头的应用程序。你所描述的看起来像是一场灾难。让我们简要回顾一下三层体系结构的外观以及工作原理：

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

对于哪一层应该知道其他哪一层，有不同的思想流派。但是从我所读到的，我认为你应该把业务逻辑作为一种中介来推广。这意味着，业务逻辑知道表示层和数据层，但其他层彼此不知道。我尝试通过两个示例场景来澄清这一点：

A.显示现有用户

业务逻辑要求数据层提供特定的

用户

DAO，例如与

id==123

对应的DAO

数据层返回

用户

对象

业务逻辑读取存储在

用户

对象中的值，并相应地设置表示层中的值，例如

firstName

、

lastName

等。它不转发

用户

本身，只转发包含的值

B.创建新用户

表示层收集创建新用户所需的所有值

当“提交”时，这些值到达业务逻辑（例如IoC）

业务逻辑告诉数据层使用从表示层获得的值创建一个新的

User

对象

数据层创建并存储对象

在不同层之间创建依赖关系的是DAO。也就是说，如果您的表示层要实例化一个

用户

对象，它需要导入一个属于DAL的类（这不是您的老板想要的）。 因此，您可以做的是将表示层和数据层之间的所有通信留给业务逻辑

作为场景B中的替代方案，您还可以让业务逻辑创建

用户

，从而使DAL方法变得更简单

---

正如我一开始所说，没有一种方法可以做到这一点。如果您需要更具体的信息或有进一步的问题，请毫不犹豫地提问。

感谢您提供迄今为止的所有答案和指南

我认为我的老板想要的（我没有联系到他，因为他在DE，我在RO）是完全分离层之间的关注点，比如模型视图表示模式，这样表示层（UI）就不会直接访问数据层。它可以通过中间层访问它

我向应用程序添加了一个域/服务层，现在表示层调用服务层，服务层调用业务层并创建用户/组对象

下面，他谈到了这个域层应该包括的业务规则。这些业务规则是什么，请举个例子

对于业务规则，我唯一想到的是一些验证规则，例如：在调用之前：return userRepository.GetUserName（User-User）检查作为非null参数传递的用户对象，或者类似的检查

所以现在的“机制”是：

在表示层中，我将IService对象注入构造函数，然后使用IService对象调用一个方法，例如“GetAllUsers（）”

IService本身实际上是用户对象的Repository类的“副本”，因此当IService对象调用“GetAllUsers（）”时，IService类中有一个精确命名的方法将执行此操作：“return _userRepository.GetAllUsers（）”—这样