0

I have watched the active record classes in our project grow into large, do-it-all classes. When you need anything about a user, for example, you should go to the Person class. While this makes perfect sense when you consider the domain, in reality, the Person class is a mishmash of lots and lots of functionality, which do get modified sometimes as the domain becomes clearer, which means both SRP and OCP are violated.

Is this one of the things that comes with the Active Record pattern, or are we doing it wrong?

Improve this question
1
  • From what I hear, AR probably makes creating such a mismash easier, but I would also venture a guess that your application suffers from a lack of partitioning. E.g. a User can mean a lot of different things in different contexts: security, sales, profiles, et al.. Don't lump all these concerns in one class. Commented Feb 12, 2014 at 9:22

3 Answers 3

Reset to default
6

The typical use of AR violates these principles. Many developers dump every possible piece of functionality into their models making them fat and cumbersome. The fact that AR makes database interactions an afterthought aids in the misuse.

What you could do is make use of the repository pattern.

Use it to separate your data persistence code from the business logic thus hiding away the details of AR. Then separate your use cases into single responsibility classes. Recently this has been dubbed DCI and it's starting to gain some traction. This will keep your models uber-light and use cases will become more clearly articulated in real classes. Learning to make use of DCI takes some practice but there are a growing number of resources out there and really, once you grok the concept, you shouldn't have much trouble using it. (Don't worry if you make some initial mistakes.)

By taking this tack you wouldn't be tightly bound to AR. You could very easily create interfaces that use the filesystem or any sort of persistence. By making your persistence layer more of an afterthought, you'll have improved your architecture dramatically.

Improve this answer
3

No. AR pattern does not violate SRP.

One needs to understand the use case of an AR pattern before using it in their application. Active Record Pattern has to be used where the domain logic isn't complex such as an app which involves just simple basic operations like CRUD. Reference: Patterns of Enterprise Application Architecture by Martin Fowler

AR pattern makes it simple the data access to and from the database as it ties the data access layer to the domain model.

Improve this answer
0
0

No, AR does not violate SRP. Modeling a User is a single responsibility. Mixing in persistence via AR does not make the User class responsible for persistence. The AR framework is responsible for persistence. Recording relationships between the User class and other classes still doesn't make the User class responsible for persistence. Those relationships are facts about the user model.

If you add methods to the User class that fetch and store Users and Roles and other objects then you are violating SRP. Those methods are not part of the User model, and belong in some service class.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.