Use MVCRSH instead of MVC.
Tags: programming, productivity
Published: 2024-03-11 16:28:27

There is a famous style of programming which most of you already knew "MVC" it's even inbuild in frameworks like Laravel and ROR.
You can also apply this style to frontend framework like flutter, Vue and React for better productivity.
Today I want to share an extended version of MVC which we all should use instead of MVC to keep code clean and healthy. 
**It's MVCRSH - Model, View, Controller, Routes, Services and Helpers.** 

## What is MVC?
MVC (Model, View, Controller) is architecture for dividing our code in application.

## Why we need to extend it?
MVC might be an good style for keeping things separated but there will be sometimes when you will get confused if the particular piece of code should be put in Controller or Model. 
 
## Model
![Models](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/reblozmc9dqbps6t42ic.jpeg)
Model should contain only definition of entity or database table, The field it contains, type of fields, foreign-key etc.

1. To define our list of fields we can define an array or object. In array you can only suggest field names while in object you can also provide their data types.
2. We can define relationship with help of functions to fetch related data, In most ORM we can define what kind of relationship do we want with other entities and fetch data accordingly.
3. We can also define Accessor or Mutator to run some condition before fechting or saving data.
4. Here's the list of famous ORM w.r.t frameworks which provide model functionality, for Laravel it's Eloquent, for Node it's Drizzle or prism, for Flutter it's Sqflite.
 
## View
![Views](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ecdql5r87aoqd8c488t6.jpg)
View should only contain UI part, which user sees or interact with. For web It ultimately compiles to HTML, CSS and JS.
Hence all the files related to it come inside view.
1. We can define which layout do we wan to use.
2. When using frontend framework, reactive data and js methods also comes into picture.
3. Along with it, more complex things like frontend routing and state management start to fill the view part. 
With tools like Inertia or File based routing we can eliminate frontend routing code.
4. Here's the list of famous templating engine w.r.t frameworks which provide UI functionality, for Laravel it's Blade, for Express it's pug, for Flutter it's Flutter.

## Controller
![Controllers](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q126cgfvhqub0qqq3rx6.jpg)
Controller as we know should only contain business logic but there's lot of logic like validation, running big query, sending email, generating csv or excel and using services like Twilio, stripe, gmap etc.
1. We should only call functions to above all use cases inside controller, the way we call model inside controller.
2. Validation can be call before executing controller function like middleware. Framework like Laravel provide dependency injection for doing the same.
3. Rest of the things will move to services and helpers.
4. Controllers should contain only single word functions like create, update, delete, index, show, download, csv, excel etc

## Routes
Routes as we all know are starting point of user entry in application, hence it's most simple and absolute one.
Most framework provide routing by default, In framework like flutter you can use get_router or getx to define routes. 

## Services
Services should be made in way, so that they can be used in any other project like ApiService, CsvExport, ExcelImport, TwilioSms, Mailchimp.
1. The code in services should always be reusable so it can be used in any project.

## Helpers
Last but not the least, Helpers provide help to controller and model. The logic or function which makes controller bulky should be moved to helpers instead of models. Most developers confuse between Utils and helpers but they are not the same.
In frontend frameworks, state management tools are kind of helpers only. In backend frameworks you need to create one otherwise you would end up writing most of the bulky logic inside controller or model. Helper pattern can be better alternative to repository pattern here's how:

1. Helper class should extend particular modal class. Hence we can use helpers instead of models everywhere with extended functionality without breaking the quality of models.
```php
namespace App\Helpers;
 
use App\Models\User;
class UserHelper extend User {}
```
2. We should not use Services and Jobs inside helpers, same as model, We can however access other helpers to perform dependency operation.
3. The meaning of this class is to help model entity perform tasks, the controller methods are more of crud operation, and models methods are limited to database only, hence we need human readable and doable tasks in form of methods inside helpers.
For eg. UserHelper will contain methods like
getFriendsList, getPhotos, getRecentPosts
4. While working between multiple models/helpers, most beginners get confused and create duplicate methods like 
PostHelper->getRecentPostsForUser
While doing so we must remember which primary or single entity we want data for. 

I hope you find this post useful for whatever framework you use.
Thank you and have a nice day!