1

Currently im injecting my Unit of Work inside the controller.

I figured out that in most of the designs, controllers calls the service layer and service calls the repository/DAL layer.

Most of the times in the controller, I don't have/need any logic and just need to fetch from db and pass it to view.

I do this by calling the repository from the unit of work, is this a bad practice?

I basically have only a two layered architecture instead of a 3 tiers. Im kinda missing the service layer/application layer

Views(MVC) <- Controllers(MVC) -> UoW(DB) -> Repository(DB) -> EF(DB) -> SQL Server(DB)

For the interested i can send my git repo in private.

  • 3
    Questions containing the words "bad practice" are unanswerable unless you can articulate your specific concerns. Clearly it already works. – Robert Harvey Apr 3 '19 at 17:13
  • 3
    You don't have to implement abstractions you don't need, regardless of what the "good practices" say. – Laiv Apr 3 '19 at 17:38
3

If you don't really have any logic beside fetching data from the repository and showing it, then it is perfectly fine to skip a separate service/application layer. In fact it would be a bad practice to have an extra layer in that case, since you would be complicating the architecture for no benefit.

You can always introduce a new layer at a later point if the need arises.

|improve this answer|||||
  • "You can always introduce a new layer at a later point" I agree with the YAGNI-centric answer, but I do want to add a footnote here that for sufficiently large codebases, inserting another layer can become a considerable task. If there's a reasonable expectation that this may be necessary in the future, it can be better to pre-emptively already set the layer up (even if it's just a passthrough at the moment). Nonetheless, +1 from me as overengineering can be as much of a problem as underengineering. – Flater Jan 6 at 12:31
  • @Flater it will be the same amount of work to introduce it whether you do it prematurely or when it is actually needed. – JacquesB Jan 7 at 8:36
  • I adamantly disagree. Do note that I said "for sufficiently large codebases". The larger a codebase is, the more troublesome a rewiring becomes (compared to building it right the first way). – Flater Jan 7 at 9:52
  • @Flater Agree, it is obviously more work to introduce on a larger codebase that on a smaller. But having a superfluous extra layer will make it more work to grow a smaller codebase to a larger, so you just distribute the work over more time. – JacquesB Jan 7 at 10:42
  • I can agree with that for small codebases. The combined conclusion is then that the larger a codebase is/will be, the more you should favor pre-emptive layering. For small codebases, it can be put off until necessary. For large codebases, it's generally more beneficial to pre-empt (at least earlier than you would for a small codebase). – Flater Jan 7 at 11:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.