开发不依赖于表示层的应用层？
我正在学习一般的发展策略，但我心中有很多关于它们的问题。其中之一是关于创建不应依赖于表示层的应用程序层。 例如，在 MVC 应用程序中，假设我们有应用程序服务，但该应用程序服务不检查来自表示层的传入数据模型的验证。它仅通过 ASP.NET MVC 验证在控制器中进行检查，而且服务层内部不包含任何授权内容。所有工作都在表示层完成。您认为这是正确的架构吗？我是否必须再次将所有验证和授权包含在服务层内？如果你说是，但是怎么样？
如何在服务层中包含授权？我真的不知道如何控制服务层内的授权。在服务层中重复验证可以吗？
毕竟，如果我确信表示层永远不会改变，那么这样的设计真的值得吗？
I am learning general development strategies but there are a lot question in my mind about them. One of them is about creating application layer which shouldn't have dependencies Presentation layer.
For example, in MVC application lets say we have application services but this application services doesn't check validation for incoming data models from Presentation layer. It is only checked in controller via ASP.NET MVC validations also service layer doesn't include any authorization stuffs inside. All job is done in Presentation layer. Do you think that is it correct architecture ? Do i have to include all validation and authorizations inside service layer re-again ? If you say yes but how ??
How can i include authorization in service layer ? I really don't know how to control auhthorizations inside service layer. Duplicating validations in also service layer could be ok ?
After all Is it really worth to make such as design if i am sure presentation layer will never change ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
验证应该在领域层进行。在 DDD 应用程序中，域（业务）层应该拥有验证权，因为它最了解自己。服务层在域上运行，并且应该处理由域层引发的错误，包括验证错误。在这种情况下处理错误可能意味着将其包装在服务层异常中并返回错误代码、记录错误等。授权也应该是服务层的责任。这并不是说表示层（ASP.NET MVC）不应该执行验证或授权验证。表示层中的验证通常比域和服务层中的验证更轻量级，这样做是为了改善用户体验。毕竟，如果大部分验证可以在客户端执行，为什么不这样做并省去服务层呢？同样的逻辑也适用于授权。
关于验证逻辑的重复，没有解决方案可以满足所有情况，有时您必须接受一点重复以降低整体复杂性并提高可维护性。在域层进行验证的最简单方法是使用标准防护并抛出 ArgumentException 实例。在 ASP.NET MVC 中，进行验证的最简单方法是使用数据注释属性。通常，在某种程度上复制验证逻辑比实现包罗万象的验证系统更容易。此外，可能存在只能由域层执行的验证，这是将它们分开的另一个论点。
服务层中的授权可以通过多种方式完成，具体取决于所使用的底层技术。如果使用 WCF，有许多用于授权的指南。
Validation should be in the domain layer. In a DDD application the domain (business) layer should own the validation since it knows most about itself. The service layer operates upon the domain and should handle errors, including validation errors, raised by the domain layer. Handling an error in this case could mean wrapping it in a service layer exception and returning an error code, logging the error, etc. Authorization should also be the responsibility of the service layer. This is not to say that the presentation layer (ASP.NET MVC) should not perform validation or authorization verification. Validation in the presentation layer is typically more light-weight than validation in the domain and service layers and is done in order to improve the user experience. After all, if most of the validation can be performed on the client side, why not do it and save a trip to the service layer? The same logic applies for authorization.
In regards to duplication of of validation logic there is no solution that will fulfill all cases and sometimes you have to accept a little duplication to reduce overall complexity and improve maintainability. The simplest way do do validation in the domain layer is using standard guards and throwing ArgumentException instances. In ASP.NET MVC the simplest way to do validation is using data annotation attributes. Often times it is easier to duplicate validation logic to some extent than it is to implement an all encompassing validation system. Moreover, there may be validation that can only be performed by the domain layer, which is another argument for keeping them separate.
Authorization in the service layer can be done in many ways and depends on the underlying technology used. If using WCF there are many guidelines for doing authorization.