DAL with entity framework and Enterprise framework

Hello experts,

I was wondering if someone would have a sample n-tier application using the entity framework, multiple sql databases so I can work out how to build the dal for such a project??
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

XGISAuthor Commented:
Some assistance would be appreciated
Kumaraswamy RCommented:
XGISAuthor Commented:
yeah Thanks for the response although that confirms that I can use one or the other but I have since decided to stick with entity framework and don't know how to build dal and since there are multiple multi-tenant databases it just adds extra complexity and need either an online tutorial that fits this scenario (that I have not found after two weeks of searching or a sample that implements the scenario
Learn Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

Are you going to be using EF4? There's a big difference between EF4 and EF1. The disparity in version numbers is due to the EF4 being named after the .Net framework 4.0. (It should really be EF2). If you are going to be working with EF4, I can show you some example code I think.

Also, many people claim they're writing an nTier application when in reality they're writing a multi-layered application. Will you truly have your DAL running on one machine, your business logic on another machine and potentially your presentation laying running on another machine or will this all be running on the same physical machine.

Not to say you don't know what you mean there just seems to be some confusion in the field when it comes to these terms.
XGISAuthor Commented:
it will all be web delivered..... yes I understand you concerns, I will be using ef4 and maybe you are correct I intend to have multiple multi-tenant dbs an entity model (maybe edmx for each db then have them as nested under a core model unsure at this point), dal, bll, services, ui and network balancing not to mention security and network health layers....
Hmm, depending on you "core model" you may need to go POCO, possibly with self-tracking entities to leverage some of the "niceties" of the EF4. If you're going to be building on an inheritance model from your code you're going to want to deviate from the default edmx model and at least go the custom template route for a more granular control.

I really recommend going pure POCO here as a separate layer that is serializable (which should be very easy). That way you can easily pass your business/data model objects across machine boundaries via XML/SOAP or whatever you choose. This makes your question a very generic "XML/Soap" nTier communication issue of which there are thousands of examples and you're no longer looking for EF4 examples.

If you're going to develop a serious nTier application POCO is really the way to go as it gives the most flexibility while completely detaching the business object (or model object) from the serialization (to database, not XML communication).

Does this make sense and sound like the direction you want to head?


Is a good starter example of wiring up the POCO mapping by hand. This is obviously more work but it gives complete freedom as well. Your model objects and/or business objects can reside in a stand-alone assembly that just contains simple classes.

You can write service layers to interact with those classes at any level and/or tier you want... Keep your service layers either primitive (accepting only .net CLS-compliant data types or your simple POCO objects) There are pros and cons to both approaches.

There are other decisions of course, web services or WCF, etc. ad nauseam. All of these types of decisions have ample examples on the net of course.

Let me know if you're looking for more specific information on particular scenarios using the EF4.
XGISAuthor Commented:
thank you.... until now I have been beating my head against the wall... lol I had heard a little about POCO and I will research it thoroughly... and yes i intend to use WCF services..

The only other question I can think of before I issue the points  would you have an example of "POCO, possibly with self-tracking entities to leverage some of the "niceties" of the EF4. If you're going to be building on an inheritance model from your code you're going to want to deviate from the default edmx model and at least go the custom template route for a more granular control. " so I can understand and get a starting point??

The main problem I ran into when using the "built-in" inheritance model of the EF4 is that you end up with one "master" table of indexes. You can toy with this and you'll quickly see what I mean. In my case, I wanted to create a "base" data object that all tables/other data objects would derive from. This base data object had all the good-practice properties like "ID", "DateAdded", "DateModified" and "Name" field / properties. As I started deriving all my tables/data model objects from that I noticed the inherited properties/fields were all going in one massive master table with relationships built off this table. Obviously, that was unacceptable as I would have one table with as many rows as all of my other tables combined! Just a heads up and warning...

This is a great example that I follow like religion every project I do when I want to go the self tracking route. Self tracking lifts a lot of the heavy mapping code as well as keeping track of "what's changed" in your object tree, as well as, and just as important "what has not changed". The self-tracking gives you all of the "niceties" of the edmx model while providing the complete abstraction of POCO business objects from the database serialization code itself (relationship, keys, constraints, etc.)


Please note that I use business object, data object and model object synonymously. The reason being there really is no good reason that I'm aware of the add another layer on top of the POCO objects in regards to creating a business logic layer. You really have two reasonable choices here. Either add the business logic into your POCOs themselves or create a service layer. It's really a personal decision and architecture goal you're trying to achieve. If you're going to allow "public" access to your logic I would recommend a service layer as you have complete easy-to-understand access points to your business logic.

A brief example: User Sign In

SQL Table


POCO (data object) (same for both approaches)

class WebUser

string Name { get; set; }
string Password { get; set; }
string Salt { get; set; }
string Email { get; set; }

now you can integrate your business logic into your data object WebUser like so

class WebUser
public bool SignIn(string password)


provide a service layer that uses very specific access points

class AccountService
    public WebUser SignIn(string username, string password)

I personally prefer the latter as it completely locks down the public access points to the business logic (provided I don't add any public logic to the WebUser class itself)

The drawback is that any time your method stamp changes it cascades. In this sample that would be rare but what about OrderService.PlaceOrder(username, accountNumber, email, address1, address2, ..., shippingAddress1, shippingAddress2, etc.)

You can see where you might want to pass POCOs here so that OrderService.PlaceOrder(currentUser, account, orderItems) always remains the same method call-wise. As long as there's no logic inside the POCOs themselves you have a tight-knit service layer. Your POCOs are just a means of going from SQL -> XML -> WCF -> (another machine) -> WCF -> ASPX (or whatever)

Hope that helps. I realize the architecture info was a bit out of scope but I wanted to share some caveats and lessons I've learned while working with the EF4 since beta.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
T4 templates inside Visual Studio, best resource and collection of resources:

XGISAuthor Commented:
Thankyou so much as this cleared up a lot of concerns that I had.... It can get rather perplexing with the amount of architectures out there and finding one that is extensible whilst maintain manageable code
I couldn't agree more. Microsoft has been unleashing tools and architectures so fast I basically wait for the trend, select the best choice I can make and stick to it. I avoided EF1 but EF4 is really the way to go now that LinqToSql is all but dead. Best of luck to you.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
.NET Programming

From novice to tech pro — start learning today.