Aspect-Oriented Programming in OOP world - breaking rules ?

Question

Hi 2 all!

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.

Answer 1

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.

Answer 2

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.