Ratko Ćosić - lamentations of one programmer

"A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes. Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers."
- Martin Fowler (Patterns of Enterprise Application Architecture)

Repository pattern is very intriguant one, as it troubled myriads of developers through years. Also, I have had some experience on doing such, as well as using some proprietary 3rd party application architecture models.

...

The problem with the business objects is that they cannot be mapped with the data storage objects without our intervention. This issue have troubled many software architects for years. While developing their own frameworks, or adopting their existing architecture to, somewhat, misterious solutions, they has been no good answers on doing it.
Well, we have had some solutions, but personally, somehow it just do not fit into my paradigm of thinking.

Please, feel free to visit the blog the see how I'm going with the lammentation about the ORM which I consider investing in the future.

I plan to begin with the NHibernate, then switch to LINQ, and finish with the ADO.NET Entity Framework, which is promising child.

Kind regards,
Ratko

You can start to follow my lamment by clicking here!