使用 Spring AOP、规范模式和策略模式进行业务规则和验证
我在 Spring 应用程序标准架构（控制器 -> 服务 -> DAO...）中确实遇到验证和业务规则编程（设计）问题。
一点一点地，服务层类正在因丑陋的 if-s 而变得过载，天真的重构方法统一了类级别上的一些常见验证等。简单地说，所有这一切都需要一个进行更多的重构实践以使代码更易于维护。
我了解业务规则管理系统以及 Hibernate Validator 之类的东西，但如果可能的话我不想使用第三方解决方案。
最近，我读到域驱动程序设计和规范模式对于业务规则组织来说似乎是有吸引力的解决方案。我也读到过关于 Spring 和 DDD 结合的不同观点。
因为我是初学者，可能我的想法看起来很幼稚，但我正在考虑将 Spring 框架的 AOP 功能与规范模式结合起来作为制定业务规则和逻辑的便捷方法。在这种组合中，AOP 将仅用于在特定服务方法中插入特定业务规则。作为一些扩展，我认为也许策略模式将有助于定义不同的验证策略。
但是，出现了很多问题。如何根据验证上下文、类数量爆炸、模式过度使用等改变策略？
我只是想听听关于这个想法的一些想法以及关于上述问题的建议。谢谢
I really have trouble with validation and business rules programming(design) within Spring application standard architecture (controller -> service -> DAO...).
Bit by bit, service layer classes are becoming overloaded with ugly if-s, naive-refactored methods which unifies some common validations on class level etc. Simply, all this requires a some more refactoring practice to make code more maintainable.
I know for Business Rule Management Systems, and things like Hibernate Validator, but i don't want to use third party solutions if possible.
Recently, I read about Domain Driver Design and Specification pattern looks like attractive solution for business rules organization. I have also read different views about Spring and DDD combination.
Because i'm beginner, probably my idea will look naive, but i was thinking to combine AOP capabilities of Spring framework and Specification pattern as convenience approach to formulate business rules and logic. In that combination, AOP would be used just to insert specific business rule in specific service method. As some extension, i thought that maybe Strategy pattern will help for defining different validation strategies.
But, many questions arises. How to variate strategy according to validation context, class number explosion, pattern overusage etc?
I just want to hear some thoughts about this idea and advices about mentioned problem. Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论