2

There are so many conflicting articles online. What's your personal opinion on this (for an enterprise app).....

In my C#/MVC app I've setup my architecture as suggested here, minus dependency injection and automapper: https://chsakell.com/2015/02/15/asp-net-mvc-solution-architecture-best-practices/

In general, when speaking of the MVC controller, should it only deal with the service layer directly? Or is it still good practice to deal with the repository directly? What would help you to decide?

Also, should the UnitOfWork class be created at the controllers level then passed into Service/repo?

Thanks

WebDevGuy2
  • 1,159
  • 1
  • 19
  • 40
  • http://stackoverflow.com/questions/8735466/fat-model-thin-controller-vs-service-layer seems related – Peter Ritchie Jan 25 '17 at 16:37
  • I much prefer this kind of architecture https://lostechies.com/jimmybogard/2013/12/19/put-your-controllers-on-a-diet-posts-and-commands/ – CSharper Jan 25 '17 at 17:58

4 Answers4

4

Well, Unit of work, I think is useless as DBContext could be the unit of work, Also you could use the DbContext as repository. Do I need repository and service layers, I think just one of them is enough depends on the complexity of the project, service is layer is when you have more complex project. You should think of how you could re-use your code, and keep it simple, but not to create a lot of layers, with non reusable code

Tarek Abo ELkheir
  • 1,311
  • 10
  • 13
2

In general repositories contain minimal possible code. I mean they only contain code for inserting, updating and removing items from internal implementation. They exist because you want to switch DAL implementation. If you want to use repositories directly in controller, then you must write domain logics in the controller and it is not a good practice. Controllers have to be small and only forward requests to domain logic or services.

So in my idea it's better to use services in controller.

If you instantiate UOWs in your services you will ended with a new unit of work in every service. creating unit of works may be expensive. So if you need two or three service in one controller you will have two, three unit of work in one controller.

So again in my idea it's better to inject unit of work to services.

I say again Repository and Unit of work is useful if you want to switch DAL implementations (example can be testing code with in memory data).

MRB
  • 3,752
  • 4
  • 30
  • 44
1

Personally, I feel that the service layer is of utmost importance for any medium-sized to large API, and that it is at that level that you should deal with the unit of work (if you decide to use one). The reason you should not deal with the repository at the controller level is for flexibility in your architecture and to prevent tightly coupling your service to your protocol or your implementation.

As an example, assume today you are exposing your service as a REST service. Tomorrow, you may want to use another protocol (maybe SOAP or something else). By using the service layer, the protocol layer (controllers) becomes throw-away and can easily be replaced.

Another example, which encourages service layer along with dependency injection would be if at some point in the future, you want to change the implementation of your service, you would have to change code starting from the controller instead of just creating and injecting your new implementation.

At the end of the day however, the above are just opinions and possible scenarios that could or could not apply to your project. The choice you make should depend on the nature of your specific project (size, complexity, probability of change, ...).

GPicazo
  • 6,516
  • 3
  • 21
  • 24
0

Well it really depends on your application.

Let me give you an example of architecture that I would use.

  1. MVC site project
  2. Business layer project
  3. Persisten layer project
  4. Common layer project
  5. Tests project

1 Controllers, Views, ViewModels. This is where you transfrom your BL models into ViewModels.

2 Your business layer. This can be omitted if your BL is on Database and you are only interested in Displaying data. However if you starting new project this is where you BL should be. All your business decisions, validations an so on. Also if you BL model doesn't match your database this is where you would transform your database data into BL models

3 This layer is just for talking to database. With minimal logic.

4 Common object. Like Extension methods. Or other objects used through application. This should be as light as possible!

5 This is where you write tests for you application - this can be splitted into multiple projects if you prefer to have a project for every layer

Notes:

1 - Here you should also think about your View and how will you separate concerns between Controller, ViewModel and your HTML, javascript etc... This really depends on complexity of your views.

I recommend you using Dependency injection it is great tool escpecially if you are building enterprise application.

xszaboj
  • 1,035
  • 7
  • 21