OOP 世界中的面向方面编程 - 打破规则？
当我从事 ASP.NET MVC 网站项目时，我研究了不同的验证方法。其中一些是 DataAnotation 验证和验证块。他们使用属性来设置验证规则。像这样：
[Required]
public string Name {get;set;}
我很困惑这种方法如何与 OOP 世界的 SRP（单一责任原则）相结合。另外，我不喜欢业务对象中的任何业务逻辑，我更喜欢“糟糕的业务对象”模型，但是当我用验证属性来装饰我的业务对象以满足实际需求时，它们变得丑陋（有很多属性/具有本地化逻辑和很快）。
属性的想法非常简单，但在我看来，验证装饰应该与对象分开。我不确定将验证规则分离到 xml 文件或其他对象的方法，也许这是一个解决方案。
AOP 的另一个不好的方面是这样的代码中的单元测试问题。当我用自定义属性装饰一些控制器操作时，例如在操作之间导入/导出 TempData 或初始化一些所需的服务，我无法编写适当的单元测试来测试此操作。
您是否认为属性不会破坏srp，或者您只是忽略这一点并认为这是最简单的，而不是最糟糕的方法？
PS我读了一些喜欢的文章和讨论，我只是想把事情按正确的顺序排列。
PPS 抱歉我的“流利”英语:=)
编辑 我认为“违反规则”和丑陋会出现在这样的场景中： 如果验证有一些业务规则 - 例如用户必须在系统中具有唯一的电子邮件，您应该验证用户输入，将所有您的层扔到应用程序中，因此当您编写自定义属性来检查此数据时，业务对象将与你的数据层抛出属性。
When I worked on asp.net mvc web site project, I investigated different approaches for validation. Some of them were DataAnotation validation and Validation Block. They use attributes for setting up rules for validation. Like this:
[Required]
public string Name {get;set;}
I was confused how this approach combines with SRP (single responsibilty principle) from OOP world. Also I don't like any business logic in business objects, I prefer "poor business objects" model, but when I decorate my business objects with validation attributes for real requirements, they become ugly (Has a lot of attributes / with localization logic and so on).
Idea with attributes realy simple, but in my opinion the validation decoration should be separated from object. I'm not sure is the approach to separate validation rules to xml files or to another objects, maybe it is a solution.
Another bad side of AOP - problems with unit testin such code. When I decorated some controller actions with custom attributes for example to import/export TempData between actions or initialize some required services I can't to write proper unit test for testing this actions.
Do you think that attributes don't break srp or you just disregard this and think that it's simplest , is not worst way ?
P.S. I read some likes articles and discussions and I just want to put things in proper order.
P.P.S. sorry for my "fluent" english :=)
EDIT
I think that 'breaking rules' and ugly will be in such scenario:
In case when validation has some business rules - for example users must have unique email in system, you should to validate user input throw all youe layers in app, so when you write your custom attribute to check this data, business object will be connected with your data layer throw attribute.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
AOP 本身并没有违反任何 SOLID 规则，尤其是 SRP。
如果您在业务对象中使用 UI 验证属性，那么它肯定会破坏 SRP。但如果你在特殊的 UI 类中使用这些属性，即 UI 和 BL 之间的接口，那么一切都满足 SRP。
AOP by itself doesn't break any SOLID rule, especially SRP.
If you use UI validation attributes inside business object, then it definitely breaks SRP. But if you use such attributes in special UI classes, which is intended to be interface between UI and BL, then everything satisfies SRP.
我相信验证规则与您用于 UI 的模型对象有关。事实上，它们用一组约束来描述每个数据，这些约束定义了该数据的值是否可接受。
我也一直在努力解决这个问题，但我相信装饰方法很好，因为你设置了它然后忘记了它：如果你有外部验证，那么你有可能忘记应用验证，并最终得到无效数据。
我曾经使用验证 getter 和 setter，这是一个可怕的想法。
有一种简单的方法可以将关注点分离到不同的位置：使用分部类。像平常一样定义您的类，但将其设置为部分类，然后使用单独的文件来定义字段及其装饰：它们将合并到类中，而不会给您的代码带来太多细节。
I believe that validation rules pertain to the model objects you are using for your UI. In fact, they describe each of your data with a set of constraints, which define whether the value for that data is acceptable or not.
I have struggled with this too, but I believe that the decoration approach is good, because you set it up and forget it: if you have external validation, then there is a chance that you forget to apply validation, and end up with invalid data.
I used to employ validating getters and setters, and that was a horrible idea.
There is an easy way to separate the concerns into separate places: use partial classes. Define your class as you would normally but set it as partial, then use a separate file to define the fields and their decorations: they will get merged into the class, without littering your code with too many details.