Active record pattern: Difference between revisions

Revision as of 17:54, 12 July 2022

Latest revision as of 23:18, 31 October 2023

(11 intermediate revisions by 8 users not shown)

Line 1:

{{Short description|Concept in software engineering}}

In [[software engineering]], the '''active record pattern''' is considered an [[Architectural pattern (computer science)|architectural pattern]] by some people and as an [[anti-pattern]] by some others recently.<ref>[https://www.mehdi-khalili.com/orm-anti-patterns-part-1-active-record ORM anti-patterns - Part 1: Active Record]</ref> 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.

The active record pattern is an approach to accessing data in a [[database]]. A [[database table]] or [[View (database)|view]] is wrapped into a [[class (computer science)|class]]. Thus, an [[object (computer science)|object]] instance is tied to a single row in the table. After creation of an object, a new row is added to the table upon save. Any object loaded gets its information from the database. When an object is updated, the corresponding row in the table is also updated. The wrapper class implements [[accessor]] [[Method (computer programming)|methods]] or properties for each column in the table or view.

Line 7 ⟶ 8:

== Implementations ==

Implementations of the concept can be found in various [[Software framework|framework]]s for many programming environments. For example, if there is a table <code>parts</code> in a database with columns <code>name</code> (string type) and <code>price</code> (number type), and the Active Record pattern is implemented in the class <code>Part</code>, the pseudo-code

{{sxhl|2=ruby|1=

part = new Part()

part.name = "Sample part"

part.price = 123.45

part.save()

}}

will create a new row in the <code>parts</code> table with the given values, and is roughly equivalent to the [[SQL]] command

Line 20 ⟶ 21:

Conversely, the class can be used to query the database:

{{sxhl|2=ruby|1=

b = Part.find_first("name", "gearbox")

}}

This will find a new <code>Part</code> object based on the first matching row from the <code>parts</code> table whose <code>name</code> column has the value "gearbox". The SQL command used might be similar to the following, depending on the SQL implementation details of the database:

Line 31 ⟶ 32:

== Criticism ==

=== TestabilityLarge files ===

Because the data and the database access methods are in the same file, those files end up being bigger.

Due to the coupling of database interaction and application logic when using the active record pattern, unit testing an active record object without a database becomes difficult. These negative effects on testability of the active record pattern can be reduced by using [[mock object|mocking]] or [[dependency injection]] frameworks to substitute the real data tier with a simulated one.

=== 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.

=== Distributed systems ===

Record-based patterns work poorly in distributed systems especially where concurrency is impossible (e.g. offline). i.e. two updates both may have one field that is correct but only one of the two records can win.{{Clarify|date=August 2018}}

== See also ==