If you’ve been programming for some time, you have likely worked with many design patterns without realizing it. Design Patterns are simply patterns of writing code that developers have noticed over time. Very often Design Patterns are best-suited or commonly applied to a similar programming problem such as an Object-Relational-Mapper.
When working with a database, developers will quickly turn to an Object Relational Mapper (ORM) for mapping their database schema to classes. These ORMs hide all the SQL gook and allow us to interact with the database using .Net, Java or other tools. These tools make use of many Enterprise Design Patterns under the hood.
- Active Record – Encapsulates a single database row and the domain logic related to it.
- Data Mapper – Moves data between a database and object.
- Unit of Work – Handles changes made to objects and writes them to the database in a single transaction.
- Identity Map – Ensure each object is only loaded once.
- Lazy Load – Dependent objects are loaded only when needed instead of all at once.
- Identity Field – Store a database Primary key in an object. Is this really a pattern?
I find I use Design Patterns most when building a new system from scratch. You can save time and build a better system by leveraging the experience codified in Design Patterns from other developers. Patterns also useful when discussing a system with other developers. The common vocabulary is very useful for when someone describes how the Service Layer utilizes Transaction Scripts to modify the Domain Model!