Thanks for the reply. Do you have a link to the Tasks extension from JP Boodhoo so I can look over the source code. I am familiar with JP. Do you have a link...
Hello Justin, Here is a link to the relevant blog entry: http://blog.jpboodhoo.com/CommentView,guid,744e085e-efe8-4b63-b6b8-46d53b61e757.aspx For the very...
Thank you. I've also emailed you off list. Regards, Justin ... From: "Eben Roux" <eben@...> To: <domaindrivendesign@yahoogroups.com> Sent: Monday, June...
All, I have the following layers in my project: App.UI App.Presentation App.Services App.Domain.Model App.Domain.Repositories App.Infrastructure.DataAccess I...
... I don't see why not. Personally I would prefer to have some services in a seperate namespace in the Domain assembly, though. My domain contains only model...
... From: "asbjorn.hoegh" <ahoegh@...> You should only have an address repository if you're address is an aggregate root, i.e. makes sense outside the...
All, Is the repository considered part of the domain or part of the infrastructure? I am reading the book .NET Domain-Driven Design with C# and the author has...
The interface for the repository is part of the domain, but the actual implementation depends on the storage type (database, file...) used so that is tied to...
... From: Jesper De Temmerman A RepositoryFactory handles retrieval of the correct implementation of the repository interface (by hand or with an IoC framework...
... From: Jeff Lowe I typically define the repository interfaces in the domain model. Their implementation would be in the infrastructure layer. ... Thanks...
public interface ICustomerRepository { Customer GetCustomerWithId(int id); ... } A repositoryfactory could then look like public class RepositoryFactory { ...
... From: Jesper De Temmerman You should not have your domain objects call the repository. Instead, use a service. For example: public class CustomerService { ...
A repository should only exist for aggregate roots. If you want to persist changes to a customer address, you have to go through the customer (the aggregate...
... From: Jesper De Temmerman A repository should only exist for aggregate roots. If you want to persist changes to a customer address, you have to go through...
You do pretty much anything to help persist or retrieve data inside the repositories, and in small projects the easiest way to do this is to write your...
... From: Jesper De Temmerman You do pretty much anything to help persist or retrieve data inside the repositories, and in small projects the easiest way to do...
... From: Jesper De Temmerman As for your other question, I prefer to keep the service class with the domain object and repository interface, it makes sense to...
Hello Justin, It is the responsibility of the PersonRepository to handle the Person *Aggregate Root*. So if the Address is an aggregate root then the...
Hey Justin, The repository interfaces are defined in the domain. However, if one goes for a CQS idea as some suggest on the forum (you know who you are) where...
... It could be, but you could also put it in your Domain. That's what I do. I have services for all my complicated repositories in a namespace in my domain. ...
Hi Justin, ... You could change this a little, to "The single responsibility of the CustomerRepository is to process Customer *aggregate* data", since the...
Hello Justin, OK, let me try this again... my last post (or two) went missing! Yes the Repository Interfaces are in the domain (the old dependency inversion). ...
I prefer not to have any layers above the service layer that do not facilitate going to the UI. It is okay to turn DO's from services into DTO's to send over...
... From: "Eben Roux" <eben@...> However, should one follow a CQS approach where there is only a single fetch for the aggregate root on the repository,...
... From: "asbjorn.hoegh" <ahoegh@...> Imagine the following namespaces in each assembly: App.Infrastructure.Repositories App.Infrastructure.Factories ...
... From: "asbjorn.hoegh" <ahoegh@...> It could be, but you could also put it in your Domain. That's what I do. I have services for all my complicated...