Question

I have been learning Backend development for quite a while now and I decided to build a bigger project using Express.js and the MVC architecture, the project is basically a Restful API with Vue.js in the frontend (it may contain some real-time communication later as well). Since I am not from a CS background, I have stumbled upon multiple resources about how to architecture my application and it felt somewhat overwhelming.

To make it clear, I will tell you what I understood regarding the MVC, what I wanted to do, and I will show you a screenshot of my current design, all I need is a friendly criticism with guidance from an experienced developer without complicating stuff.

While I was building my application, I anticipated that as my code grows, it looks ugly and harder to maintain, so I stopped and started thinking about architecturing my application for a couple of days before jumping into writing the code.

The MVC architectural pattern splits the code into three logical components, the model, the view, and the controller. Where the view is the layer with visuals, for example the UI or JSON for a Restful API request. The model is the layer that interacts with the database, it sometimes contains the "business logic" of the application. Finally the controller just receives the request, calls a method from the model, and returns back the response to the user. I found that it is debatable whether to add the business logic inside the model or inside the controller.

In all cases, when the application code grows in size, it would be hard to maintain the code, since the controller/model will grow accordingly resulting in a big fat controller/model that is harder to maintain and test, also it doesn't make sense for me to add all the business logic in any of the controller or the model. Thus, we could make a layer (service layer) just between the model and the controller that contains our business logic in a SOLID way, we could also have multiple utility classes.

Here's a screenshot with the design I came with. This post is open for anyone who wants to share his idea about the MVC architecture and provide some guidance, resources, or useful criticism. This is my first draft, please correct me if you see something that is wrong, or could be done better.

Regards, Hazem

Note: I have posted the same question on stackoverflow.

My current design draft

Était-ce utile?

La solution

If you were to imagine 2 versions of your application, one for desktop use and one as a mobile app, both with the same functionality. Then the Model part of the MVC pattern should contain everything that is common between the two applications, which comes down to all the actual functionality. For an application of any size, that will indeed be a huge amount of code. For that reason, it is very common that the Model part of the MVC pattern has a further internal structure based on other design/architectural patterns.

If I map the sketch of your design on the MVC pattern, I come to the following mapping:

  • MVC View: Frontend (plus the not shown code to build the JSON used for communicating from backend to frontend)
  • MVC Controller: Route, Middleware, Controller
  • MVC Model: Service Layer, Model (Data Access), Database

This is a perfectly valid initial architecture. Depending on what your application does, you might want to split the Model (Data Access) into multiple classes, corresponding to different entities in the application.

For the Middleware it is debatable if it really is a part of the MVC Controller or if it should belong to the MVC Model. I have chosen for the MVC Controller, because the when/how the Middleware gets used depends on the specific implementation of the MVC Controller/MVC View interaction and that can change if you put a different kind of user interface on the application.

Licencié sous: CC-BY-SA avec attribution
scroll top