Home/ Questions/Q 4021316
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-20T10:20:12+00:00

I am using the UnitOfWork/Service Layer/Repository/EF4 w/POCO design in my MVC app. So far

  • 0

I am using the UnitOfWork/Service Layer/Repository/EF4 w/POCO design in my MVC app.

So far I have this:

1) MVC Web App (Project.dll)
2) Service Layer (Project.Data.Services.dll)
3) Repository Layer (Project.Data.Repositories.dll)
4) POCOS (Project.Data.Domain.dll)
5) EF4/Context Layer (Project.Data.dll)

Each layer only reference the layer beneath and the Project.Data.Domain (POCO Classes).

I currently have the UnitOfWork Interface/Base in the Project.Data.dll, but now all the layers have to reference that. Is that a bad design? And if so, where does it live?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It’s just an opinion.

    Domain objects are part of business. Same for contextes and repositories.

    In fact, my point is OR/M is an abstraction over a relational database or other kind of stores so these can act as an object-oriented store.

    That’s OR/M throws away data layers in modern software solutions.

    Repositories, domain context, domain objets are part of business layer.

    Unit of work is a software design pattern and it’s not only for working with databases, or a data layer, but it can manage more things, like a networked transaction. I’d suggest this should be included in some namespace like “YourCompany.YourProject.Patterns.UnitOfWork” or something like that.

    A service has nothing to do with data. I’d like to suggest a “YourCompany.YourProject.Services” namespace.

    Another point is your POCOs seems to work as DTO too, because you’re using everywhere, even for passing data through layers and/or tiers. This could be ok in a naked objects implementation or something like that, but you’ll need to pay attention to the fact of using domain objects as DTO, because they may contain properties, information, behaviors or OR/M proxying hidden members that may affect objects’ weight – memory usage -.

    Taking last paragraph fact, I’d suggest you to work with DTO in any layer on top of business, so your services would return DTOs with the specific range of properties that service consumers would need to work fine.

    DTO, patterns’ implementations and such things shared in all projects part of your solution should be living in some project called “YourProject.Shared” and this assembly mustn’t reference to any layer: it must remain layer-neutral, so referencing it everywhere doesn’t force to have useless dependencies.

    Well, this is my opinion and way of working in my projects.

    • 0