Activerecord as a model, is that a good idea?

Question

Recently, thanks to the popularity of rails, many people are starting to use activerecord as a model. however, before I heard about rails (my peer group was not a fan of open source materials, we were taught at the .NET school ...), and when I was doing my last project, I found this definition for the model

The model represents enterprise data and business rules governing access to and updating of this data. Often a model serves as a program approximation to a real process, therefore, when determining a model, simple methods of modeling the real world are used.

he does not say that the model should represent one table, as activerecord does. And, as a rule, inside a transaction, you may have to query several unrelated tables, and then manipulate data from different tables ... therefore, if the activerecord function is used as the model, then any of them will have to insert all the logical code into the controller (which popular in some php frameworks), which makes it difficult to validate or hack the activerecord model, so that it works with the database not only with the table to which it is bound, but also with other related tables ...

So, what is so good about abusing (IMHO) activerecord as a model in the MVC architectural pattern?

Answer 1

Martin Fowler described this pattern in enterprise application architecture patterns along with two other patterns or architectures. These patterns are good for different situations and varying degrees of difficulty.

If you want only simple things you can use Transaction Script. This is the architecture that you saw on many old ASP and PHP pages, where one script contains business logic, data access logic, and presentation logic. It quickly falls apart when things get complicated.

The next thing you can do is add a separation between the presentation and the model. This is activerecord. The model is still database bound, but you have a bit more flexibility because you can reuse your model / dataccess between views / pages / independently. It's not as flexible as it could be, but depending on your data access solution, it can be quite flexible. Frames like CSLA in .Net have many aspects from this patterm (I think the Entity Framework is too much like that). He can still cope with great difficulty without becoming overwhelming.

The next step is to separate your data access level from your model. This usually requires a good OR block or a lot of work. Therefore, not everyone wants to go this route. Many methodologies, such as domain-based design, take this approach.

So this is all a matter of context. What you need and what is the best solution. I even still use transaction script for simple one-time code.

Answer 2

I have said many times that using Active Record (or ORM, which is almost the same) as business models is not a good idea. Let me explain:

The fact that PHP is Open Source, Free (and this whole long story ...) provides it with an extensive community of developers laying code on forums, sites like GitHub, Google code, etc. You might see it as good, but sometimes it is not so "good." For example, suppose you are facing a project and want to use the ORM structure to solve your problem written in PHP, well ... you will have many options for :

• Doctrine
• Propel
• QCodo
• numbness
• Redbean

And the list goes on and on. New projects are created regularly. Imagine that you have built a full-blown structure and even a source code generator based on this structure. But you did not post business classes, because, in the end, "why write the same classes again?" Time goes by and a new ORM structure is released and you want to switch to a new ORM, but you will have to modify almost all client applications using a direct link to your data model.

The bottom line, active record and ORM are for the data level of your application, if you mix them with your presentation level, you may run into problems like this example that I just put.

Listen to @Mendelt wise words: Read Martin Fowler. He has contributed many books and articles on the design of OO and published some good material on this subject. In addition, you can look at Anti-Patterns , more specifically in the Lock In Provider , what happens when we make our application dependent on third-party tools. Finally, I wrote this blog post talking about the same issue, so check it out if you want.

Hope my answer was helpful.

Answer 3

The great thing about using Rails ActiveRecord as a model in MVC is that it gives you an automatic Object Relational Mapper (ORM) and an easy way to create associations between models. As you already indicated, MVC can sometimes be absent.

Therefore, for some complex transaction involving many models, I would suggest using a presenter between your controller and your models ( Rails Presenter Pattern ). The presenter integrates your models and transactional logic and will be easy to verify. You definitely want to strive to keep all of your business logic in your models or presenters and from your controllers ( Skinny Controller, Fat Model ).