0

I'm trying to learn dependency injection. The book/example I am following seems to be using an MVC project as just the UI layer within a broader architecture. The example includes a separate project for the domain layer and yet another project for the data access layer.

When I first learned MVC I came away thinking MVC was the entire architecture. V for view for UI layer, C for controller for domain layer, and M for model for data access layer.

So is using an MVC project as only the UI layer a proper and/or commonly accepted application of the MVC framework?

Alan
  • 1,587
  • 3
  • 23
  • 43
  • MVC is not framework, it is pattern – Miknash May 19 '17 at 14:42
  • It took me a while to understand your comment & I finally see why your statement is correct, but as they say, there's more to the story. It's my fault; wasn't really clear when I said MVC; was speaking to MVC as a Visual Studio project. So while MVC is clearly a pattern, an MVC project is a framework. Not trying to start an argument, but it might be possible for less experienced people such as me to be confused reading this. https://stackoverflow.com/questions/320142/design-patterns-vs-frameworks & https://en.wikipedia.org/wiki/Software_framework, the latter being what I meant to say above. – Alan May 26 '17 at 18:36

2 Answers2

1

Applying SRP to the MVC design pattern will lead you there. Same goes for MVVM. You are extracting logic from Model to other classes like Interactors, Services, Repositories etc.

From any point of view this is perfectly normal(and desirable). Your Model is just an abstraction of Several different layers.

I would suggest you to take a look at VIPER (not a car) - https://www.objc.io/issues/13-architecture/viper/ and you will see something that is occuring to you right now.

Miknash
  • 7,888
  • 3
  • 34
  • 46
1

So is using an MVC project as only the UI layer a proper and/or commonly accepted application of the MVC framework?

Yes.

While it is possible to make an application entirely within the context of ASP.NET MVC, doing so means that the application will have to be written from scratch to use a different UI framework. Isolating the business logic into a separate set of services that are not coupled to ASP.NET MVC means that only the top layer would need to be replaced to move to a different UI framework, which also means that the application's lifecycle may extend beyond the end of ASP.NET MVC and/or it can be made into an application with a different UI framework (WebApi, WPF, etc) without too much trouble.

The purpose of dependency injection is to decouple your services from all other parts of the application, including each other. So by extension, it is only natural to build the business layer separately from the UI layer. Whether you physically have them in one assembly or multiple is really just a matter of preference.

NightOwl888
  • 55,572
  • 24
  • 139
  • 212
  • The example I'm following seems to take MVC into yet another direction I didn't anticipate. The author suggests splitting up the MVC project into a Presentation layer and the UI layer. Is that also a common, or advisable architecture? I've never considered that a Visual Studio MVC framework would be split up, placing controller and models in a different project. Will this create difficult problems or does it actually help in the long run? Thx. – Alan May 30 '17 at 13:00
  • 1
    @Alan - It depends. Every layer of abstraction you make provides more opportunities for extending the application down the road, providing more seams to inject components. However, every layer of abstraction comes at a cost of additional maintenance/development time. It is up to the designer of the application whether the extra abstraction level warrants the extra cost of development and maintenance for a given scenario. – NightOwl888 May 30 '17 at 13:58
  • But in principle, pulling the Controllers and Models out of the base MVC project is OK if you've decided to 'pay' that price? – Alan May 30 '17 at 15:28
  • 1
    Not usually. Doing something like making plugins that each have their own controller and views would warrant that, but most applications do not. My answer above is referring to *services* that execute *domain (business) logic*. This separates every business algorithm or function so the business domain is not tied to the presentation layer, which in turn means that you can swap to another presentation layer (maybe not even a web-based one) without having to redesign the business layer or any layer below it, such as the data layer(s). – NightOwl888 May 30 '17 at 15:42
  • 1
    When using DI, it is possible to choose from many different architecture types to build the business layer. I personally find that using [CQS](https://cuttingedge.it/blogs/steven/pivot/entry.php?id=91) is somewhat simple because it doesn't require so much knowledge about design patterns to be able to use. Also see [this sample](https://github.com/Code-First/CQS-Sample) and search for "cqs code sample" for other helpful articles. – NightOwl888 May 30 '17 at 15:53
  • Got it. Great link for the Git hub project, which I will study. I have been trying to learn this concept in order to better understand the PRISM framework. It's slow going, but you certainly helped. – Alan May 30 '17 at 16:14