Which layer do I put Reposiotry/UnitOfWork in C# solution? RRS feed

  • Question

  • I'm building a solution and want a BLL, DAL, and a web app UI project in it. I'm also learning how to impelement the Repo/UoW patterns. My DAL uses EntityFramework ORM. I've never really built a multi layered project like this and have a million questions. I haven't experienced or seen an entire multi-layered application before. I just got done coding the DAL where I placed my Repository and UoW infrastructure including Generic Repo, Interfaces, and my Entity Interfaces and concrete Repos. Should this be moved to the BLL?
    • Edited by HTHP Wednesday, June 21, 2017 2:46 PM changed DLL to DAL
    Wednesday, June 21, 2017 2:23 PM

All replies

  • Business Logic lives in the Business Logic Layer, the clues in the title ;) The data layer is about persisting and fetching the data, it shouldn't contain decision or business rules. This shouldn't be confused with tiers. For example, a store procedure that decides how much discount to give is a business rule that lives in the data tier. 

    Out of interest, what are you using UoW for in a web app?


    Wednesday, June 21, 2017 7:12 PM
  • I've seen so many examples where things like UserRepository and CustomerRepository live in a BLL, and others where it lives in a DAL. I'm wondering why I see this. I take it you think they should live in the DAL?

    Do you think that a Web App somehow shouldn't implement the UoW pattern? I'm actually doing it because I want to learn these patterns and this will help me gain experience.

    I'm fuzzy on the difference between a "Service Layer", Business Domain Layer, and Application Domain Layer. It seems to me that the Business/Application Domain is pretty much the same except in really complex cases. And that Business and Application Domains are really a type of "Service Layer" themselves.

    I always thought of Layers as logical breakdown of software sections in an application, and Tiers as physical or virtual locations where servers, storage, and such things actually "live".
    Wednesday, June 21, 2017 9:30 PM
  • In it's pure sense a Repository is about abstracting out the underlying persistent store. I can see how you might argue it lives in the business layer but IMO it doesn't. Ask yourself what business rules does it implement? If it is implementing business rules what is it's responsibility, does it look like it's having more than one responsibility? 

    As I mentioned previously, ask yourself why are you using UoW? What is UoW giving you, what's its purpose? In this case how will UoW rehydrate an object with that specific Id? How is that going to work when you have 1 user compared with a million users? Ask yourself why is that different between an always connected and disconnected scenarios. 


    Wednesday, June 21, 2017 10:30 PM
  • I'm using a UoW to coordinate and house all my repos and then to finally persist the tracked changes back to the database in one shot. My UoW is just wrapping an EF generated DbContext using Database First approach. All repos in the UoW get passed that same context. I guess I could find somewhere else to commit the changes like calling SaveChanges from the repos themselves. But UoW is the least confusing option I could think of in order to coordinate the persistance of a transaction.

    I don't really know how a UoW would reydrate an object. I hope the DbContext from EF has the ability to detect changes made to the database before it committed its changes.

    There is so much to learn, I am just jumping in an seeing what works. No matter how much research I do, I always find a couple weeks, or months later, I learn something new that may change everything I thought was true. So, I here I am trying to figure it out. There is so much misinformation out there, its hard for a solo dev in a company like myself to learn the right path.
    • Edited by HTHP Wednesday, June 21, 2017 11:05 PM typo
    Wednesday, June 21, 2017 11:04 PM
  • Given you are receiving data from a browser client, what is it that UoW is giving you? Given you are almost certainly only sending a sparse part of the data from the browser client, what work is EF going to have to do to prepare and compare the items...for 1 user and then 1 million users?


    Sunday, June 25, 2017 7:09 PM