Active record pattern: Difference between revisions

Content deleted Content added
Reverted 1 edit by 85.48.184.164 (talk): Not remotely
Distributed systems: deleted section as it was complete nonsense, it's very much possible to update only some fields of a record - it does not matter whether the code for it is in the record itself or in a separate controller.
Tag: section blanking
Line 37:
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]] 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 ==