我对OOP中的Arhitecture Designs相当陌生（我来自编程机器人技术，所以这有点麻烦）。我参与的团队正在创建一个相当大的应用程序，而领先的项目经理向我们提出了要求，在这些要求中，我们必须使用层来创建模块。我们使用的技术是C＃WinForms和Oracle用于数据存储。
我的模块由用户管理组成，并且我尝试将逻辑与实现分开，因此我具有以下架构：
业务层
资料层
表示层
我正在使用带有EF的存储库模式和IoC，一切看起来都不错，但现在我的老板告诉我，我需要将表示层与数据层完全分开。问题在于，我从表示层使用IoC，例如，如果要创建User对象，请执行以下操作：
_userRepo.InsertNewUser(new User { props here } ); .
所以这是不正确的，因为我直接访问DAL。我的老板告诉我，我需要另一层隔离这些呼叫并实现业务规则（？！）
我已经搜索并研究了互联网，但没有发现任何帮助（主要是因为这里的所有内容都在工作中被过滤掉了）。
我认为我的老板想要一个域层/服务层，但是我不知道如何在当前设计中实现它。我可以毫无问题地发布项目，所有敏感数据都将从代码中删除。
任何帮助，将不胜感激。
最佳答案
我将其发布为答案，即使它可能是基于意见的，即使我看不懂您老板的想法:-)
从根本上讲，我认为您的老板想要的是减少所有层之间的依赖性。您选择执行的架构模式取决于手头的应用程序。您所描述的看起来像three-tier architecture。让我们简要回顾一下三层体系结构的外观以及事物应该如何工作：
表示层显示信息并充当用户的边界。
应用程序层（或业务逻辑）控制应用程序的功能。特别是，它处理数据并将其分发到其他层。
包含数据访问层（DAL）的数据层存储或检索数据。它应该使您的应用程序独立于存储解决方案。通常它将与数据访问对象（DAO）一起使用。
当涉及到哪个层应该知道其他层时，存在着不同的思想流派。但是从我的阅读中，我认为您应该将业务逻辑作为一种中介来推广。这意味着，业务逻辑知道表示层和数据层，但其他层彼此不认识。我尝试通过两个示例场景来阐明这一点：
A.显示现有用户
业务逻辑向数据层询问特定的User DAO，例如对应于id==123的那个。
数据层返回User对象。
业务逻辑读取存储在User对象中的值，并相应地在表示层中设置值，例如firstName，lastName等。它不转发User本身，仅转发包含的值。
B.创建一个新用户
表示层收集创建新用户所需的所有值。
当“提交”时，这些值到达业务逻辑（例如IoC）中。
业务逻辑告诉数据层使用从表示层获得的值创建一个新的User对象。
数据层创建并存储对象。
在不同层之间创建依赖关系的是DAO。即如果您的表示层要实例化User对象，则需要导入属于DAL的类（这不是您的老板想要的）。
因此，您可以做的是将表示层和数据层之间的所有通信都留给业务逻辑。
作为方案B的替代方案，您还可以使业务逻辑创建User，以使您的DAL方法变得更简单。
正如我在一开始所说的那样，没有一种方法可以做到。如果您需要更多具体信息或有其他疑问，请随时提出。
关于c# - N层应用设计，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/29073383/