locked
What is the standardized approach to define controllers in MVC RRS feed

  • Question

  • User1052662409 posted

    Hi All,

    I already have a web application asp.net web forms.

    I have many modules in this web application like Leave Management, Travel Management, Project Management etc.

    Now I am converting it into MVC from scratch . I already started working on it. I have set up entity framework for database related operations.

    But as I go to the controller part I found that I can make all methods in one controller (all I mean the methods including all modules Leave Management, Travel Management, Project Management etc.)

    But I thought that when the project will be completed it would be hard to maintain those all methods in one controller. So I decided to make one controller for each module.

    Am I on the right path or is there any other things which I need to take care?

    And also I should do in case of Models?

    Please suggest.

    Thanks

    Thursday, April 25, 2019 3:29 AM

Answers

  • User1120430333 posted

    But as I go to the controller part I found that I can make all methods in one controller (all I mean the methods including all modules Leave Management, Travel Management, Project Management etc.)

    That's not good and you have fat controllers when you should have skinny controllers with unneeded logic moved out of the controller to classes/objects in the Models folder, which is the domain.

    https://docs.microsoft.com/en-us/aspnet/mvc/overview/older-versions-1/overview/understanding-models-views-and-controllers-cs

    <copied>

    An MVC model contains all of your application logic that is not contained in a view or a controller. The model should contain all of your application business logic, validation logic, and database access logic.

    A view should contain only logic related to generating the user interface. A controller should only contain the bare minimum of logic required to return the right view or redirect the user to another action (flow control). Everything else should be contained in the model.

    In general, you should strive for fat models and skinny controllers. Your controller methods should contain only a few lines of code. If a controller action gets too fat, then you should consider moving the logic out to a new class in the Models folder.

    <end>

    https://en.wikipedia.org/wiki/Business_logic

    <copied>

    In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed. It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program.

    <end>

    But I thought that when the project will be completed it would be hard to maintain those all methods in one controller. So I decided to make one controller for each module.

    There is nothing stopping you from making domain classes/objects in the Models folder where a controller or controllers  can use the behavior/methods of a domain object. And there is nothing stopping you in making one domain object use the behavior of another domain object.


    Am I on the right path or is there any other things which I need to take care?

    IMO, you're not on the right path in using MVC.

    https://www.c-sharpcorner.com/UploadFile/56fb14/understanding-separation-of-concern-and-Asp-Net-mvc/

    http://www.bradoncode.com/blog/2013/08/repository-vs-domain-model-vs-data.html

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, April 25, 2019 6:36 PM

All replies

  • User1520731567 posted

    Hi demoninside9,

    But I thought that when the project will be completed it would be hard to maintain those all methods in one controller. So I decided to make one controller for each module.

    Am I on the right path or is there any other things which I need to take care?

    I agree with your thinking.

    I am also used to dividing different modules into different controllers.

    Because this not only facilitates the division of labor and code maintenance, but also helps users to clearly search for URLs.

    The URL pattern "{controller}/{action}/{id}" So,there will be some urls,like:

    http://xxx/Leave/Create

    http://xxx/Travel/Create

    http://xxx/Project/Create

    ...

    And also I should do in case of Models?

    Similarly, I suggest that you can also write different models separately.

    More details,you could refer to this link about mvc:

    https://docs.microsoft.com/en-us/aspnet/mvc/overview/getting-started/

    Best Regards.

    Yuki Tao

    Thursday, April 25, 2019 8:29 AM
  • User475983607 posted

    I generally end up with two types of controllers; a very basic repository and a facade.   The repo handles lookup tables involved in user selection things that can be cached or very basic CRUD operations.  The facade is the entry point for application features (an API) with well defined inputs and outputs.

    And also I should do in case of Models?

    Which models, MVC, Entities, or something else?  MVC models should exist in the MVC project.  Entities go with Entity Framework.  Usually, you'll have simple classes (POCOs) that travel between the MVC app and data access.

    Thursday, April 25, 2019 1:28 PM
  • User1120430333 posted

    But as I go to the controller part I found that I can make all methods in one controller (all I mean the methods including all modules Leave Management, Travel Management, Project Management etc.)

    That's not good and you have fat controllers when you should have skinny controllers with unneeded logic moved out of the controller to classes/objects in the Models folder, which is the domain.

    https://docs.microsoft.com/en-us/aspnet/mvc/overview/older-versions-1/overview/understanding-models-views-and-controllers-cs

    <copied>

    An MVC model contains all of your application logic that is not contained in a view or a controller. The model should contain all of your application business logic, validation logic, and database access logic.

    A view should contain only logic related to generating the user interface. A controller should only contain the bare minimum of logic required to return the right view or redirect the user to another action (flow control). Everything else should be contained in the model.

    In general, you should strive for fat models and skinny controllers. Your controller methods should contain only a few lines of code. If a controller action gets too fat, then you should consider moving the logic out to a new class in the Models folder.

    <end>

    https://en.wikipedia.org/wiki/Business_logic

    <copied>

    In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed. It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program.

    <end>

    But I thought that when the project will be completed it would be hard to maintain those all methods in one controller. So I decided to make one controller for each module.

    There is nothing stopping you from making domain classes/objects in the Models folder where a controller or controllers  can use the behavior/methods of a domain object. And there is nothing stopping you in making one domain object use the behavior of another domain object.


    Am I on the right path or is there any other things which I need to take care?

    IMO, you're not on the right path in using MVC.

    https://www.c-sharpcorner.com/UploadFile/56fb14/understanding-separation-of-concern-and-Asp-Net-mvc/

    http://www.bradoncode.com/blog/2013/08/repository-vs-domain-model-vs-data.html

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, April 25, 2019 6:36 PM
  • User1052662409 posted

    a very basic repository and a facade

    I need exact. But this is first time I am doing So I want to go with the standard approach. If I go with the wrong way so that would be almost impossible to come back and make thing again in right way.

    Sir, do you have any reference or example? Can I have a look so that I can get an idea or approach to go fuhrer.  

    Friday, April 26, 2019 3:31 AM
  • User1052662409 posted

    Which models

    I mean Model (domain) classes.

    Entities

    For that I am using LINQ to Entities. I think this is the latest approach to handle database the earlier was LINQ to SQL. May be I am wrong but I guess.  

    Friday, April 26, 2019 3:38 AM
  • User1120430333 posted

    demoninside9

    mgebhard

    a very basic repository and a facade

    I need exact. But this is first time I am doing So I want to go with the standard approach. If I go with the wrong way so that would be almost impossible to come back and make thing again in right way.

    Sir, do you have any reference or example? Can I have a look so that I can get an idea or approach to go fuhrer.  

    The repository pattern is a domain pattern in DDD, which is NOT the generic repository that is erroneously being  used by developers.

    https://martinfowler.com/eaaCatalog/domainModel.html

    https://martinfowler.com/eaaCatalog/repository.html

    https://programmingwithmosh.com/net/common-mistakes-with-the-repository-pattern/

    https://blog.sapiensworks.com/post/2012/03/05/The-Generic-Repository-Is-An-Anti-Pattern.aspx

    Friday, April 26, 2019 4:46 AM
  • User1120430333 posted

    demoninside9

    mgebhard

    Which models

    I mean Model (domain) classes.

    mgebhard

    Entities

    For that I am using LINQ to Entities. I think this is the latest approach to handle database the earlier was LINQ to SQL. May be I am wrong but I guess.  

    You shouldn't confuse the domain model with the persistence model that can easily be confused with the many teaching of using the MS's ASP.NET MVC  UI design pattern and the usage of an ORM in the ASP.NET MVC  UI design pattern.

    https://blog.sapiensworks.com/post/2012/04/07/Just-Stop-It!-The-Domain-Model-Is-Not-The-Persistence-Model.aspx

    You could learn how to architect, like using a  layered or a  combination of architecture styles.

     https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ee658117(v=pandp.10)

    https://www.dofactory.com/products/net-design-pattern-framework

    I like the last summarization post made by the original poster of the thread about  ASP.NET developers and the usage of  the ASP.NET MVC UI design pattern. :) Excellent!

    https://forums.asp.net/t/2155030.aspx?Robert+C+Martin+vs+Martin+Fowler

    Friday, April 26, 2019 5:14 AM