repository-pattern

How do I encapsulate the saving of more than one entity in a transactional manner using the repository pattern? For example, what if I wanted to add an order and update the customer status based on that order creation, but only do so if the order completed successfully? Keep in mind that for this example, orders are not a collection inside the customer. They are their own entity. This is just a contrived example, so I don’t really care whether orders should or should not be inside the customer object or even in the same bounded context. I don’t really care what underlying technology will be

I have a question regarding DDD and the repository pattern. Say I have a Customer repository for the Customer aggregate root. The Get & Find methods return the fully populated aggregate, which includes objects like Address, etc. All good. But when the user is searching for a customer in the UI, I just require a 'summary' of the aggregate - just a flat object with summarised information. One way I could deal with this is to call the find method on the repository as normal, and then in the application layer, map each customer aggregate to a CustomerSearchResult / CustomerInfo DTO, and send them

(Note: My question has very similar concerns as the person who asked this question three months ago, but it was never answered.) I recently started working with MVC3 + Entity Framework and I keep reading that the best practice is to use the repository pattern to centralize access to the DAL. This is also accompanied with explanations that you want to keep the DAL separate from the domain and especially the view layer. But in the examples I've seen the repository is (or appears to be ) simply returning DAL entities, i.e. in my case the repository would return EF entities. So my question is,

I'm having a hard time understanding the Repository Pattern. There are a lot of opinions on that topic like in Repository pattern done right but also other stuff like Repository is the new Singleton or again like in Don't use DAO use Repository or just take Spring JPA Data + Hibernate + MySQL + MAVEN where somehow a Repository appears to be the same as a DAO object. I'm getting tired of reading this stuff since imho this can't be such a hard thing as it is displayed in a lot of articles. I see it like this: It appears that what I want is something like this: -----------------------------------

I am wondering how should I be grouping my repositories? Like from the examples I seen on the asp.net mvc and in my books they basically use one repository per database table. But that seems like a lot of repositories leading you to have to call up many repositories later on for mocking and stuff. So I am guessing I should group them. However I am not sure how to group them. Right now I made a registration Repository to handle all my registration stuff. However there are like 4 tables I need to update and before I had 3 repositories to do this. For example one of the tables is a license table.