where does the model go?

Question

I have a VS solution, with the following projects.

-GUI
-DataAccess
-BusinessLogic
-BusinessObjects

but where should the main model class reside? This is usually a cache of a set of objects which are the results from the data access layer and the GUI using virtual grids to view data inside the model. The question would be the same using MVC or MVP

thoughts?

Answer 1

My solutions have 3 (non-test) projects

1. UI - obvious
2. Core - all domain objects and business logic
3. Data Access - Repository pattern for populating/saving Model objects

Answer 2

This is a subjective question, but often to enforce that your model objects don't have direct dependencies to infrastructure, people often put them in a separate project. you also need to consider what other projects might use these model objects.

Another option for splitting up functionality into separate deployable units (assemblies) is so that teams can function more independently. Separate projects based on frequency of deployment and team autonomy.

Lastly I've seen some projects where the model objects were invoked remotely (like with .NET remoting) and served up on an application server separate from the web server. I really don't recommend this approach, but it's an option.

If you don't plan on reusing them, and you're cognizant of the fact that placing them in the same assembly allows you to create cross dependencies with anything else defined in that project, but you're smart enough not to do it, you can place them all in the same project.

That said, 99% of the time I have these projects:

• UI
• Core
• Persistence
• Tests

But you still have to take your project needs into account.

Answer 3

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