Home/ Questions/Q 706659
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T04:11:27+00:00

I recently started reading about ASP.net MVC and after getting excited about the concept,

  • 0

I recently started reading about ASP.net MVC and after getting excited about the concept, i started to migrate all my webform project to MVC but i am having a hard time keeping my controller skinny even after following all the good advices out there (or maybe i just don’t get it … ).
The website i deal with has Articles, Videos, Quotes … and each of these entities have categories, comments, images that can be associated with it. I am using Linq to sql for database operations and for each of these Entities, i have a Repository, and for each repository, i create a service to be used in the controller.

so i have –

  • ArticleRepository
  • ArticleCategoryRepository
  • ArticleCommentRepository

and the corresponding service

  • ArticleService
  • ArticleCategoryService …

you see the picture.

The problem i have is that i have one controller for article,category and comment because i thought that having ArticleController handle all of that might make sense, but now i have to pass all of the services needed to the Controller constructor. So i would like to know what it is that i am doing wrong. Are my services not designed properly? should i create Bigger service to encapsulate smaller services and use them in my controller? or should i have an articleCategory Controller and an articleComment Controller?

A page viewed by the user is made of all of that, thee article to be viewed,the comments associated with it, a listing of the categories to witch it applies … how can i efficiently break down the controller to keep it “skinny” and solve my headache?

Thank you!
I hope my question is not too long to be read …

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This is the side effect of following the Single Responsibility Pattern. If each class is designed for only one purpose, then you’re going to end up with a lot of classes. This is a good thing. Don’t be afraid of it. It will make your life a lot easier in the long run when it comes to swapping out components as well as debugging which components of your system aren’t working.

    Personally, I prefer putting more of my domain logic in the actual domain entities (e.g. article.AddComment(comment) instead of articleCommentService.AddComment(article, comment)), but your approach is perfectly fine as well.

    • 0