Best MVC programming practices

[Olive34]

I have been tasked at work, well actually I volunteered to create an MVC site (as a demo) that will eventually be the base for moving my employer's legacy C#/asp.net code to MVC. It's a large site, used globally, and we are a small team of 5 devs. Right now I am the only one working on the MVC site, but the rest of the team will be involved eventually. I don't think any of them have any experience with MVC either.

I had zero experience in MVC before I started this task, and have been learning. Things work in the site, but I am not confident that I am following the best programming practices, other than the basics that would be the same in C#. Like, small methods, small classes, SOLID, etc. Since we are building this site from scratch, I really want to make sure it has a solid foundation.

Do you know of any resources where I can learn some of the basic concepts of good programming for MVC?

For example, one question I have right now is where to put the repository(s). The boss wants the model project (which is using Entity Framework) to be a separate project from the main project for the website. I have them separated and working. The controllers that I have working so far have code in them that really should be in a repository, and I am going to move it. The controllers are in the main project. Code in a view calls a 'get' method or something, in a controller. The controller method should call a method in a repository, which deals with all the database stuff, gets the data and sends it back.

So which project would you put the repositories in? I think it should be in the same project as the EF models, but is that a good standard? Also how many repositories should there be? One repo for each controller, or maybe for a related group of controllers? Same with ViewModels (looks like a DTO or POCO to me). Is it better to have one ViewModel per class, or a related group of them all in one class? There is going to be a lot of different types of functionality when the site is done enough to publish, and I do not want to have a hundred EF models/repos, or one gigantic one either.

Edit - there is no MVC tag and none of the others seemed to fit. ASP.NET is closest, I guess?

Edit2 - found this, in case anyone else has a similar question. https://www.c-sharpcorner.com/article/best-practice-for-mvc/

[gediminas.bukauskas.7]

You will need two class libraries (.NET Framework):

1. CRUD operations with Entity Framework,
2. Shared library with interfaces (proxy library).
   You can to create many libraries of the first type (one for every different DB type). All these libraries must to implement interfaces defined in proxy library. Connection string is the only problem is following this template. Create the Init(connection_string) method for resolving this problem.

[jkon]

I have no working experience with C#/asp.net , but here are few thoughts.

• There are many MVC implementations , keeping the structure as simple as possible with no unneeded fancy patterns will help you add complexity when it is needed.
• For many years I was completely freaked about keeping everything in Model View or Controller layers BUT ... having seen other projects I realized that also the ones that I have designed had a hidden layer ... some call it Controller Helpers or Operations. It is when you need to have some operations that the Controllers will use without creating "fat" Controllers that some Controllers might use ... e.g. verifying input fields before the Controller pass it to Model , Cache logic e.t.c.
• As I understand your base Model is actually a whole different project , so the Model of your app will only have to retrieve those data from the Model-project and transform them in a way that is useful for you app or the opposite , get the data from your app and using the Model-project update / insert them.
• There are many ways to structure your Model , here is one of them , the db object always comes from the Controller , a Data Workers layer that is only responsible for retrieving modifying inserting data , a plain objects layer (that holds the data) (e.g. POJOs) and an Instantiator layer that takes some parameters from the Controller (e.g. an id) uses the data workers layer and returns a plain object. Of course a Controller could use directly a data worker (e.g. for updating data).
• I tend to separate the Model in three layers , the first one is the main reason for its existence (e.g. Shop) the second one is the group that it is in (e.g. Product) and the third is the separation that i mentioned above (DataWorker,Plain Object,Instantiator). Each of those can have many Classes (e.g. in the group product is of course the main product POJO but there is also the ProductImage , the ProductVariation e.t.c.) , the relationship doesn't need to be one to one in those three layers , for example a product plain object could have a images list , so there is no need to create a different instantiator for this one, but when to merge is something that you will decide in each case differently.
• One thing that I have found really useful avoiding redundancy code is the Generator layer under View, that will take a plain object and generate a view out of it.

I know that my answer doesn't cover your questions about C# / asp , I hope others will cover those , I just shared some points that may ( or may not ) be useful.