• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1755
  • Last Modified:

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??
0
XGIS
Asked:
XGIS
  • 5
  • 5
1 Solution
 
XGISAuthor Commented:
Some assistance would be appreciated
0
 
Kumaraswamy RCommented:
0
 
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
0
Cloud Class® Course: CompTIA Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

 
DaveJellisonCommented:
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.
0
 
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....
0
 
DaveJellisonCommented:
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?

http://elegantcode.com/2009/12/15/entity-framework-poco-ef4-a-simple-mapping/

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.
0
 
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??
0
 
DaveJellisonCommented:
Absolutely.

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.)

http://blogs.msdn.com/adonet/pages/feature-ctp-walkthrough-self-tracking-entities-for-the-entity-framework.aspx

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

WebUsers
Name
Password
Salt
Email

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)
{
...
}

-OR-

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.


0
 
DaveJellisonCommented:
T4 templates inside Visual Studio, best resource and collection of resources:

http://www.hanselman.com/blog/T4TextTemplateTransformationToolkitCodeGenerationBestKeptVisualStudioSecret.aspx
0
 
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
0
 
DaveJellisonCommented:
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.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 5
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now