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?

John Saunders
  • 160,644
  • 26
  • 247
  • 397
Sam
  • 15,336
  • 25
  • 85
  • 148

4 Answers4

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

Kalman Speier
  • 1,937
  • 13
  • 18
2

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.

Matías Fidemraizer
  • 63,804
  • 18
  • 124
  • 206
  • @Mat - I use View/Edit Models in my MVC app and then use AutoMapper to map the pocos to the Models. – Sam Mar 03 '11 at 07:30
  • Well, I've answered you with the info you said in your question! :D Anyway, I just explained that in order to give you a right direction in naming too, because even if you use AutoMapper or anything, calling things with right naming makes sense so source code is more readable or, at least, things are found in the right places. – Matías Fidemraizer Mar 03 '11 at 07:32
  • @Mat - So you don't think that Repositories and below are data layer? I'll agree the POCO are business objects for sure, but i think the repositories and ef are data. No? – Sam Mar 03 '11 at 07:42
  • 1
    Repositories aren't "data". A repository is an entity responsible of translating business into data, and data into business, and work like a collection of objects. And EF itself isn't "data", it's an OR/M, which is an abstraction of relational data with an OOP interface, so, it's unclear a DataContext would be "data layer", since in fact, it's the Entity Framework unit of work. "Data" would be some layer of Entity Framework implementation which is asbtracted from your business. – Matías Fidemraizer Mar 03 '11 at 07:59
  • Anyway, maybe there're other opinions about that, just wait other answers and compare, read documentation and you can have a good conclusion! :) – Matías Fidemraizer Mar 03 '11 at 08:00
  • @Mat - I respect your opinion. Thanks!! – Sam Mar 03 '11 at 16:41
1

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.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
1

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.

ruslander
  • 3,815
  • 4
  • 32
  • 34