Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm trying to work a bit with Entity Framework and I got a question regarding the separation of layers.

I usually use the UI -> BLL -> DAL approach and I'm wondering how to use EF here.

My DAL would usually be something like

GetPerson(id)
{
    // some sql
    return new Person(...)
}

BLL:

GetPerson(id)
{
    Return personDL.GetPerson(id)
}

UI:

Person p = personBL.GetPerson(id)

My question now is: since EF creates my model and DAL, is it a good idea to wrap EF inside my own DAL or is it just a waste of time?

If I don't need to wrap EF would I still place my Model.esmx inside its own class library or would it be fine to just place it inside my BLL and work some there?

I can't really see the reason to wrap EF inside my own DAL but I want to know what other people are doing.

So instead of having the above, I would leave out the DAL and just do:

BLL:

GetPerson(id)
{
    using (TestEntities context = new TestEntities())
    {
            var result = from p in context.Persons.Where(p => p.Id = id)            
                    select p;
    }
}

What to do?

share|improve this question
add comment

3 Answers

up vote 7 down vote accepted

The example you provide is hardly layered architecture. I know it is intentionally simplified, but:

Your presentation layer is directly tied to the Person entity. This is OK only in simplest cases, and definitely not when you are trying to define your layers.

The GetPerson method is also using a rather bad practice of creating a new context for each call. You should get the context in the constructor, and it will be provided by your IOC container.

A simple, yet effective structure I have used is:

  • Project.Core - contains view models and interfaces.
  • Project.DAL - with my EDMX and generated code.
  • Project.BLL - business logic.
  • Project.Web - the web app itself.

It is important to note that:

  • Core is not dependent on any other solution.
  • DAL is not dependent on any other solution.
  • Project.Web depends on Core, but not on DAL nor BLL.
  • BLL depends on Core and DAL.
share|improve this answer
    
Core would appear to be a business object layer. –  sq33G Dec 21 '11 at 10:42
    
This is pretty much what I use also, however, I'd add extra DLLs to cater for interface declarations. This way you only reference the interfaces (and use something like [url=unity.codeplex.com/]Unity[/url] for DI) and you can be sure that there's no weird dependencies you've accidentally induced. –  Ed Woodcock Dec 21 '11 at 10:46
    
Normally, without EF i create my own Person class in a "Model" layer, so I have UI, BLL, DAL and Model where: UI knows BLL and Model. BLL knows DAL and Model. DLL knows Model. Do you create your own "view models" aswell and why dont you just use the ones EF generates? (i know this goes against the layered architecture, but how many times do you actually switch out the way you get data?) –  Thomas Dec 21 '11 at 11:10
    
@Thomas wrapping the view models in something abstract will make unit testing that much easier. –  sq33G Dec 21 '11 at 11:17
2  
model != view model –  Boris Yankov Dec 21 '11 at 11:26
show 9 more comments

You don't need to wrap your EDMX in anything.

If you can foresee a possibility of needing to change from EF to some other approach, you might want to extend your business objects (taking advantage of the partial classes) to implement interfaces defined in a separate Business Object layer.

Then from your code you will only deal with those interfaces and not with the concrete generated classes. A little glue code might be needed to hold this together; that with the EDMX can be your DAL.

share|improve this answer
    
So if im not foressing any changes from EF to another approach, my code above would be okay? I would then only have UI and BLL (where the EDMX is in the BLL)? –  Thomas Dec 21 '11 at 11:04
    
My pragmatic answer would be yes. With the caveat that you might actually want to put the EDMX in its own little assembly if it will be large and mostly static, so that you won't need to recompile/redistribute it as often. –  sq33G Dec 21 '11 at 11:08
    
Ah, good point about the recompile/redistribute :) –  Thomas Dec 21 '11 at 11:33
add comment

There are two general approaches to layering: strict layering and relaxed layering.

A strictly layered approach constrains components in one layer to interacting only with peers and with the layer directly below.

A relaxed layered application loosens the constraints such that a component can interact with components from any lower layer.

Using relaxed layering can improve efficiency because the system does not have to forward simple calls from one layer to the next. On the other hand, using relaxed layering does not provide the same level of isolation between the layers and makes it more difficult to swap out a lower layer without affecting higher layers.

For large solutions involving many software components, it is common to have a large number of components at the same level of abstraction that are not cohesive. In this case, each layer may be further decomposed into one or more cohesive subsystems. Figure 2 illustrates a possible Unified Modeling Language (UML) notation for representing layers that are composed of multiple subsystems.

conclusion: if you don't need the middle layer lose it; not all applications require the same approach and somehow adding a layer just for layering purpose will have penalties on the complexity cost and maintenance.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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