1

I'm (noob) re-factoring some teaching code in MVC. Using different web articles as a guide, I am placing business logic such as "add record" into a separate project. To avoid circular references, should I also move the model and other components to their own project?

Also would the BL,Model be instanciated in the controler? Thanks

kenmtb
  • 69
  • 1
  • 2
  • 13

2 Answers2

1

Typically your controller will call your business layer. It depends on the specifics, but in most situations, your business layer will call a data layer which will create the actual model objects.

Rocky Pulley
  • 22,531
  • 20
  • 68
  • 106
1

To start off with, you are better off leaving the model in the same project if the solution is a manageable size.

This will be the best way to avoid circular references. This is on the condition that the assembly you are creating won't be used by many other dependent projects and in that case, the projects could be seperated - it depends on the size and scale of your application.

e.g. For a small website application, I would structure the MVC solution in the following way - use the default folder for the Model. This will contain classes that represent the business domain objects and can be decorated with various attributes if required.

It is good to create another folder for the Data Access layer - I make a "Repository" folder for data access and this contains all calls to data sources, such as populating datasets through oledb connections, linq etc.

The controller calls the classes from the repository and populates the model objects with data. So in answer to your question, the controller creates an instance of the model and populates this model through data access layer methods.

An example is as follows:

controller code:

PurchaseOrder model = new PurchaseOrder();

string orderNumber = "123";

model.ListOfItems = purchaseOrderRepository.GetPurchaseOrderItems(orderNumber);
Robert Anderson
  • 1,246
  • 8
  • 11
  • Thanks for the wisdom. The code example nicely shows how to operate within the same project. I would like to move the business code onto it's own project to simulate a larger application where things would be more shared. In that case would GetPurchaseOrderItems get the items from something like a context or would it get the items from a model? I would think using a model would create a circular reference? – kenmtb Sep 30 '14 at 01:32
  • 1
    Hi, you can create a data access layer project that would contain the classes in the previously mentioned Repository folder. Similarly, a Business project that would contain the model objects. Then you could add a reference to those data access layer projects and business projects to your project that has the controllers & views in them. Circular references occur when there are many classes that are coupled together that are tightly coupled and dependent. If you go down the path of separate assemblies, you may also want to investigate factory patterns to create instances of those classes. – Robert Anderson Sep 30 '14 at 01:44
  • OK, that makes sense. I was assuming that the model, view and controllers had to be in the same project. If it is within good programming practices to separate them then that would be what I am looking for to help make the code more reusable. – kenmtb Sep 30 '14 at 02:02