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.

Improve this question
2
  • 3
    Questions containing the words "bad practice" are unanswerable unless you can articulate your specific concerns. Clearly it already works.
    – Robert Harvey
    Apr 3, 2019 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, 2019 at 17:38

1 Answer 1

Reset to default
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
5
  • "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, 2020 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, 2020 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, 2020 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, 2020 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, 2020 at 11:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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