i agree that the model objects go into
POCO. so lets say i have an Order
object. My question is where do i have
the class that stores a collection of
orders ??
That depends on your business. Most likely you'll have a collection of orders in a few different places...
On your customer object, each customer should have a collection of orders, so you would have one there.
If you have departments, each department should have a collection of orders they created.
If you have warehouses, each warehouse may have a collection of orders they are responsible for fulfilling.
Some objects have no parent, and that's fine. In my system, we have clients. The real-world owner of the clients is us (the business), but there is no "Us" object in the system. If you're looking to get a list of your clients (in our case) we query the repository for it.
IRespoistory<Client> repository = new Repository<Client>();
IList<Client> clients = repository.GetAllClients();
The same could apply to your orders.
I'd recommend checking out this DDD book: http://www.amazon.com/gp/product/0321268202/ref=s9k2a_c1_at1-rfc_p-3237_p?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-1&pf_rd_r=1BWAPTN787CTZXJDV5BA&pf_rd_t=101&pf_rd_p=463383351&pf_rd_i=507846
Although it is not an open source project you may find some good samples in this book: http://www.amazon.com/dp/0321268202/ "Applying Domain-Driven Design and Patterns: With Examples in C# and .NET"
You are already using the Repository pattern (your utility classes) which I'd probably use here as well. The static members can make the code difficult to test but otherwise aren't a problem. If the Repositories become too complex, break out the low-level API communication into Gateways.
Since an entity is split across multiple data sources, consider modelling this explicitly. For example: Person, HumanResourcesPerson, AccountingPerson. Use names understood by the external systems and their business owners (e.g. Employee, Resource). See Single Responsibilty Principle and Ubiquitous Language for some reasoning. These may be full Entities or just Data Transfer Objects (DTOs) depending on how complex they are.
The synchronization might be performed by an Application Service that coordinates the Repositories and Entities.
That depends on your business. Most likely you'll have a collection of orders in a few different places...
On your customer object, each customer should have a collection of orders, so you would have one there.
If you have departments, each department should have a collection of orders they created.
If you have warehouses, each warehouse may have a collection of orders they are responsible for fulfilling.
Some objects have no parent, and that's fine. In my system, we have clients. The real-world owner of the clients is us (the business), but there is no "Us" object in the system. If you're looking to get a list of your clients (in our case) we query the repository for it.
The same could apply to your orders.
I'd recommend checking out this DDD book: http://www.amazon.com/gp/product/0321268202/ref=s9k2a_c1_at1-rfc_p-3237_p?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-1&pf_rd_r=1BWAPTN787CTZXJDV5BA&pf_rd_t=101&pf_rd_p=463383351&pf_rd_i=507846
Although it is not an open source project you may find some good samples in this book: http://www.amazon.com/dp/0321268202/ "Applying Domain-Driven Design and Patterns: With Examples in C# and .NET"
10,000 foot answer:
You might find Domain Driven Design and Clean Code useful as they give you a set of patterns that work well together and a set of principals for evaluating when to apply a pattern. DDD resources: the book, free quick intro, excellent walkthrough. Clean Code resources: summary, SOLID principles.
Specific answer:
You are already using the Repository pattern (your utility classes) which I'd probably use here as well. The static members can make the code difficult to test but otherwise aren't a problem. If the Repositories become too complex, break out the low-level API communication into Gateways.
Since an entity is split across multiple data sources, consider modelling this explicitly. For example: Person, HumanResourcesPerson, AccountingPerson. Use names understood by the external systems and their business owners (e.g. Employee, Resource). See Single Responsibilty Principle and Ubiquitous Language for some reasoning. These may be full Entities or just Data Transfer Objects (DTOs) depending on how complex they are.
The synchronization might be performed by an Application Service that coordinates the Repositories and Entities.
For your needs I would recommend starting with:
Like the title says; it's basically a book on how to to DDD and TDD in a .NET environment.
A good read is Jimmi Nilssons book (and blog for that matter) Applying domain driven design
It's a mixture of Evans and Fowlers books (Domain-Driven Design - Evans), and (Patterns of Enterprise Application Architecture - Fowler)