Active record pattern: Difference between revisions

Content deleted Content added
Criticism: Deleted section on testability, because it is nonsense. It does not matter if the database operations are in the same file as the record or in a separate controller - in both cases the coupling (with respect to the unit under test) is exactly the same. You need to mock the database layer anyways, no matter where the DB access methods are located.
Adding local short description: "Concept in software engineering", overriding Wikidata description "design pattern for software that stores in-memory object data in relational databases, with interface functions for insert, update and delete, and properties corresponding to the columns in the underlying database table"
 
(One intermediate revision by one other user not shown)
Line 1:
{{Short description|Concept in software engineering}}
In [[software engineering]], the '''active record pattern''' is an [[Architectural pattern (computer science)|architectural pattern]]. It is found in software that stores in-memory object data in [[relational database]]s. It was named by [[Martin Fowler (software engineer)|Martin Fowler]] in his 2003 book ''Patterns of Enterprise Application Architecture''.<ref>[https://martinfowler.com/eaaCatalog/activeRecord.html P of EAA Catalog - Active Record]</ref><ref>{{cite book |last=Fowler |first=Martin |title=Patterns of enterprise application architecture |publisher=Addison-Wesley |year=2003 |isbn=978-0-321-12742-6 |url=https://books.google.com/books?id=FyWZt5DdvFkC&q=active+record&pg=PT187 }}</ref> The interface of an object conforming to this pattern would include functions such as Insert, Update, and Delete, plus properties that correspond more or less directly to the columns in the underlying database table.
 
Line 31 ⟶ 32:
== Criticism ==
 
=== Large Filesfiles ===
Because the data and the database access methods are in the same file, those files end up being bigger.
 
=== Single responsibility principle and separation of concerns ===
Another critique of the active record pattern is that, also due to the strong coupling of database interaction and application logic, an active record object does not follow the [[single responsibility principle]] and [[separation of concerns]]. This is opposed to [[multitier architecture]], which properly addresses these practices.{{citation needed |date=November 2019}}{{Clarify|date=August 2018}} Because of this, the active record pattern is best and most often employed in simple applications that are all forms-over-data with [[Create, read, update and delete|CRUD]] functionality, or only as one part of an architecture.{{citation needed |date=November 2019}} Typically that part is data access and why several ORMs implement the active record pattern.
[[single responsibility principle]] and [[separation of concerns]] as opposed to [[multitier architecture]] which properly addresses these practices.{{citation needed |date=November 2019}}{{Clarify|date=August 2018}} Because of this, the active record pattern is best and most often employed in simple applications that are all forms-over-data with [[Create, read, update and delete|CRUD]] functionality, or only as one part of an architecture.{{citation needed |date=November 2019}} Typically that part is data access and why several ORMs implement the active record pattern.
 
== See also ==