- It is not valid to think that relational model in database is domain model of application. They are different (except some trivial cases).
- Domain model must not contain metadata: table names, constraints, validation properties, etc. That `extra` information impacts read/write operations with network cache, makes your code hard to read over the time. Design your domain model with plain objects only.
- Most queries are simple... what is the reason for ORM?
- Complex query is easier to write in SQL, rather than search how to make it with ORM... save your time.
- Earlier or later the need to optimize certain query arise... in this case it is a bit odd try find out what is resulting SQL of my ORM call (it looks ugly as a rule). We try escape from SQL with ORM but returning in any case.
- A developer who writes repository layer can not be ignoramus in database nature: he must understand impact of what and how he is doing... only in this case there is a chance for success. If database/SQL knowledge is so fundamental and clear what is the reason to bring Chinese speech?
- The question of database refactoring arise over the time. The need for additional knowledge (ORM) complicate things. The knowledge is the power, not always.
- Alternative for database migration sounds quite good, but in reality is it demanded?
- ORM does not give me an answer to the question of security: if the set of my operations is limited to data read why there is no way to set these boundaries (and thus restrict)? Database get this resolved quite flexibly.
- Shards topic is quite popular... take a look at ORM implementation (pick any) for this simple idea... looks pretty scary.
- It is not valid to wrap web handler with decorator that manages database connections. How about user input validation, template rendering? The use of database connection session (unit of work) must be minimal, so it can serve other concurrent requests.
Wednesday, February 6, 2013
The question of persistence implementation arise often. I found repository pattern very valuable due to separation of concerns, mediate between domain model and data source (mock, file, database, web service, etc). The database data source is somewhat specific since you can proceed with SQL functions or ORM. Here are some thoughts why you might prefer SQL functions over ORM in your next project: