我对OOP中的Arhitecture Designs相当新（我来自编程机器人，所以这有点困难）。我参与的团队正在创建一个相当大的应用程序，领导项目经理向我们提出了要求，在这些要求中，我们必须使用层来创建模块。我们使用的技术是C＃WinForms和Oracle数据存储。
我的模块由用户管理组成，我试图将逻辑与实现分开，所以我有以下几个方面：
我正在使用存储库模式和IoC与EF，一切看起来和工作正常但现在我的老板告诉我，我需要完全从数据层分离表示层。问题在于，从表示层我使用IoC，如果我想创建一个User对象，我会做以下事情：
_userRepo.InsertNewUser(new User { props here } ); .
所以这是不正确的，因为我直接访问DAL。我的老板告诉我，我需要另一层隔离这些类型的调用并实现业务规则（？！）
我搜索并研究过互联网，但我没有找到任何帮助（主要是因为这里的所有内容都已过滤）。
我认为我的老板想要一些域层/服务层，但我不知道如何在当前设计中实现它。我可以毫无问题地发布项目，任何敏感数据都将从代码中删除。
任何帮助都将不胜感激。
答案 0 :(得分：1)
我发布这个作为答案，即使它可能是基于意见的，即使我看不懂老板的想法： - ）
从根本上说，我认为老板想要的是在所有层之间减少依赖。您选择执行此操作的架构模式取决于手头的应用程序。你所描述的看起来像three-tier architecture。让我们简要回顾一下三层架构的外观，以及事情应该如何运作：
当谈到哪一层应该知道哪些层级时，有不同的思想流派。但是从我读到的内容来看，我认为你应该将业务逻辑推广为一种中介。这意味着，业务逻辑知道表示层和数据层，但其他层不相互了解。我试着通过两个示例场景来澄清这一点：
：一种。显示现有用户
User DAO的数据层，例如与id==123对应的那个。User对象。User对象中的值，并相应地设置表示层中的值，例如firstName，lastName等。不转发User本身，只转发所包含的值。<强> B中。创建新用户
User对象，其中包含从表示层获得的值。在不同层之间创建依赖关系的是DAO。即如果您的表示层要实例化User对象，则需要导入属于DAL的类（这不是您的老板想要的）。
因此，您可以做的是将表示层和数据层之间的所有通信留给业务逻辑。
作为方案B的替代方案，您还可以使业务逻辑创建User，以便您的DAL方法变得更简单。
正如我在开始时所说，没有一种方法可以做到这一点。如果您需要更多具体信息或有其他问题，请不要犹豫。
答案 1 :(得分：0)
感谢您提供目前为止的所有答案和指南。
我认为我的老板想要的东西（因为他在DE并且我在RO中，我没有达到他的目的）是完全分离层之间的关注，比如模型 - 视图 - 演示模式，所以表示层（UI）不会直接访问数据层。它可以通过中间层访问它。
我在应用程序中添加了域/服务层，现在表示层调用服务层，服务层调用业务层并创建用户/组对象。
以下是关于此域层应包含的业务规则的说法。这些商业规则是什么，一个例子将不胜感激？
我唯一想到的业务规则是一些验证规则，例如：在您调用之前：return userRepository.GetUserName（用户用户）检查作为非空参数或类似检查传递的User对象。 / p>
所以现在“机制”是：
在表示层中，我向构造函数注入了IService对象，然后我使用IService对象来调用方法，例如“GetAllUsers（）”。
IService本身实际上是User Object的Repository类的“副本”，因此当IService对象调用“GetAllUsers（）”时，IService类中会有一个确切的命名方法：“return _userRepository” .GetAllUsers（）“ - 通过这种方式，表示层通过中间层调用特定于对象的方法，这个中间层将直接访问DL的某些方法。
我希望尽可能清楚地表达自己。如有必要，我会提供截图。
正如我之前所说，我只是开始接受Arhitecture Design的经验，因为在机器人领域没有这样的东西，所以请不要扔那么多岩石：D