How to deal with complex queries in MVC?

Question

Let's say you have three models, Organization, OrganizationUser, and User.

You need to handle the following reqs:

1. When a user creates an organization, they should become a user associated with that organization (a row in OrganizationUser table).

2. If any of the operations above fail, the entire "flow" should fail. This should be implemented with a transaction.

Here are the three best ways I think you can architect it:

• In the controller, create TXN, pass it to the Organization and OrganizationUser models to create their respective rows. Rollback if needed. Controller contains the business logic (has user paid, what type of org... etc).
• In the controller, call CreateOrganizationService which handles the transaction creation, abstracting it away from the controller; passes it into the models. CreateOrganizationService is where we'll keep most of the business logic
• Have Organization model require OrganizationUser model and take care of the transaction creation, the business logic, and creation of the OrganizationUser row.

Is there a better way of thinking about this, or different approaches/patterns I can apply?

Answer 1

The Controller's job is to translate incoming requests into outgoing responses. In order to do this, the controller must take request data and pass it into the Service layer. The service layer then returns data that the Controller injects into a View for rendering.

The model in MVC is not a class, it's a layer.

The Model's job is to represent the problem domain, maintain state, and provide methods for accessing and mutating the state of the application. The Model layer is typically broken down into several different layers:

Service layer - this layer provides cohesive, high-level logic for related parts of an application. This layer is invoked directly by the Controller and View helpers.

Data Access layer - (e.g. Data Mapper) this layer provides access to the persistence layer. This layer is only ever invoked by Service objects.

Value Objects / Entity layer - this layer provides simple, data-oriented representations of "leaf" nodes in your model hierarchy.

To your question: Don't put business logic or transactions into the controller. Put the business logic (and transactions) stuff into the Service class (part of the model layer).

Source

Answer 2

You can implement a service layer in between controller and repository where you can handle the business logic and making the controller clean. And all the operations related to database (CRUD) can be done in repository.

Refer this : Difference between Repository and Service Layer?

Answer 3

from your controller, you can call:

svc.CreateOrganization(<params>);

I probably wouldnt pass the model into the service. I would pass the actual data parameterized out for each piece of data b/c inside of your CreateOrganization call you should be calling into the data access layer which should use DAOs to store data.