UnitOfWork and Separation of Concerns?

Question

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?

Answer 1

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.

Answer 2

I think better if you are using Dependency Injection. You might take look at this great post: http://blog.keithpatton.com/2009/05/30/Entity+Framework+POCO+Repository+Using+Visual+Studio+2010+Net+40+Beta+1.aspx

Answer 3

Have a look at https://github.com/sharparchitecture/Sharp-Architecture it has a Northwind example which is layered like your. You will see the UnitOfWork implementation.

Answer 4

If you don't want other layers to reference Data project you must separate IUnitOfWork to separate project and use dependency injection with some Inversion of control container.