面向方面编程在面向对象的世界突破规则？

Question

当我在asp.net mvc网站项目上工作时，我调查了不同的验证方法。其中一些是DataAnotation验证和验证块。他们使用属性来设置验证规则。就像这样：

[Required] 
public string Name {get;set;} 

我被搞糊涂了这种方法如何使用SRP（单一负有责任的原则）从OOP的世界结合。我也不喜欢业务对象中的任何业务逻辑，我更喜欢“糟糕的业务对象”模型，但是当我用真实需求的验证属性来装饰业务对象时，它们变得丑陋（具有很多属性/带有本地化逻辑和等等）。

想法与属性真的很简单，但在我看来，验证装饰应与对象分开。我不确定将验证规则分离到xml文件或另一个对象的方法，也许这是一个解决方案。

AOP的另一个不好的方面 - 单元测试这样的代码的问题。当我使用自定义属性修饰某些控制器动作时，例如在动作之间导入/导出TempData或初始化一些必需的服务时，我无法编写适当的单元测试来测试此操作。

你认为这些属性不会破坏srp，或者你忽略了这一点，并认为它最简单，不是最糟糕的方式吗？

P.S.我读了一些喜欢的文章和讨论，我只是想把事情按正确的顺序排列。

P.P.S.我的“流利”英语遗憾：=）

编辑 我认为这是打破规则“和丑陋的将是这样的场景： 如果在验证具有一定的业务规则 - 例如用户必须有唯一的电子邮件在系统中，您应该验证用户输入在应用程序中抛出所有图层，因此当您编写自定义属性以检查此数据时，业务对象将与您的数据层throw属性相关联。

Answer 1

AOP本身不会破坏任何SOLID规则，特别是SRP。

如果您在业务对象内使用UI验证属性，那么它肯定会破坏SRP。但是如果你在UI和BL之间的界面中使用特殊的UI类，那么所有的东西都满足SRP。

Answer 2

我相信验证规则适用于您用于UI的模型对象。实际上，他们用一组约束来描述每个数据，这些约束定义数据的值是否可接受。

我也一直在努力，但我相信装饰方法是好的，因为你设置它并忘记它：如果你有外部验证，那么你有可能忘记应用验证，并结束与无效的数据。

我曾经使用验证getter和setters，这是一个可怕的想法。

有一种简单的方法将问题分为不同的地方：使用部分类。像通常那样定义类，但将其设置为partial，然后使用单独的文件来定义字段及其装饰：它们将合并到类中，而不会乱抛垃圾代码，因为它们的细节太多。