This approach isn't something specific only to DDD, it can be used in any application as it is a design pattern after all. net has an ICollection interface, this has nothing to do with a repository). Note that the important thing is to consider the repository a collection and not to actually implement a collection (for example. sorry to be persisted and to be retrieved from. However the persistence is viewed as a collection of objects where domain object are sent to die. This means you are free to ignore anything persistence related, but that doesn't mean that there is no persistence. In DDD, you start with the domain while the database access, in fact the persistence details, is ironed out at a later time. Of course, this is also encouraged by the database centric approach which still dominates the developers mindset and you need stronger discipline in order to keep the database access isolated. Separation of concerns is something you want in every real-life application and one of the most often met culprits when dealing with bad code is the happy mingleling of the database access all over the place. What can I say? I like clear separation between the database access and the rest of the application and this is the purpose of the Repository pattern. Made popular by Domain Driven Design, the Repository pattern is one of my favourite design patterns, which I use almost everywhere. Update: This is a much better, less technical explanation.
0 kommentar(er)
