Is ActiveRecord a bad practice?

I am starting a new project, and recently I found a project to revitalize a castle project that looks like a BIG solution, but at the same time it looks like something real, unconventional. I was wondering if this feeling is related to learning something new (and I just have to get used to it) or is it really bad practice?

+4
source share
7 answers

ActiveRecord is a design pattern first named by Martin Fowler in enterprise application architecture patterns. It is fairly common and widely used in the popular Ruby framework Rails.

This contrasts with the more conventional development style in the .Net world that the DAO should use, and this perhaps explains why you're not easy.

Suggestion: Read the source code for some Ruby on Rails applications that are similar to your own projects, and evaluate how you like the design style that results from intensive use of ActiveRecord.

+4
source

Part of what seemed strange to me to use ActiveRecord was to inherit from ActiveRecordBase<T> and have all these save methods on your object ( Save , etc.).

But it turns out you don’t have to! Instead of saying:

 [ActiveRecord] class Customer : ActiveRecordBase<Customer> { } 

You can just

 [ActiveRecord] class Customer : inherit from whatever you want { } 

and then use ActiveRecordMediator<Customer> . It has basically the same static methods as ActiveRecordBase<T> , but in this way you do not need to clutter up your object model with them. If you don’t need various protected method event locks in ActiveRecordBase<T> , this can make things easier.

+5
source

This is not a bad decision, but it has its drawbacks.

In enterprise application architecture templates, Martin Fowler describes several ways to design applications built on top of a database. These methods differ in how the application is separated from the database. He also describes that more decoupling makes more complex applications possible. An active record is described as a way to develop simpler applications, but for applications with more complex behavior, you need a domain model that is database independent and something like an object-relational resolver between them.

+3
source

ActiveRecord works great in Ruby, but is not easily ported to all languages. The central feat of AR is the metaphor table = class, row = instance. This looks pretty elegant in Ruby, because classes are also objects. In other languages, classes usually represent a special type of construction, and then you need to go through all kinds of hoops to make them work as expected. This takes away some of the natural feel that it has in Ruby.

0
source

No, this is not a bad practice. Even in .NET, this is a pretty well-established template. SubSonic ( http://subsonicproject.com ), and LINQ to SQL also uses a template.

Template implementations such as Subsonic are great for quickly and easily creating the data access layer that controls CRUD for your application.

This does not mean that it is a good solution for all systems. For large complex systems, you probably want to have less connectivity with the data warehouse.

0
source

Mixing a domain object with a service layer is the biggest bad practice (if you see it as bad practice). You end up calling user.Save (), which means that if you want to change the ORM, you rely on this template. 2 alternatives - this is a layer, which is a set of facade classes for performing your operations with CRUD or for placing inside a domain object as something like

 User.Service.Save(user); 

If you use .NET, then ActiveRecord is obviously based on ActiveRecord, Coolstorage, Subsonic, and several others .

0
source

I think that ActiveRecord has nothing to do with Castle and therefore the answers to this question. Is the ActiveRecord template to follow / promote SOLID design principles? educate many more.

0
source

All Articles