Should I refer to Entity Object class always as DAL or I can use its classes?

Let's say I have 'Customer' table in SQL DB and I'm using Entity Framework.

Now, for instance, in Controller or ViewMode开发者_StackOverflow中文版l I retrieve the customer by var customer = Page.Current.Customer when it's code is:

public class Page
{
     ...
     // Customer is EntityObject that created by Entity Framework
     public Customer Customer
     {
        get
        {
                return (new ContextEntity()).Customers.First();
        }
     } 
}

My question:

Should I refer to Entity Object class(Customer) as DAL and create CustomerWrapper or I can use it in other code of my application?

I mean, is it correct that Page.Current.Customer will return Customer Entity or I should use Customer Entity as DAL and Page.Current.Customer should return custom Customer, some kind of CustomWrapper?

In one hand if will decided to change Customer table name to site_Customer(in SQL DB) I'll refresh the EntityModel and will only change the code in the Page class to

public class Page
    {
         ...
         // Customer is EntityObject that created by Entity Framework
         public Customer Customer
         {
            get
            {
                    return (new ContextEntity()).site_Customers.First();
            }
         } 
    }

But in the other hand I'll have Customer Entity + WrapperCustomer

What is better?

All class in an EDMX file are partial classes. This means that you can extend these classes by creating a new Class file.

For example...

public partial class Customer
{
    // Here are the methods, properties, relationships created by EDMX Wizard.
}

In another area of your project, I usually put it in the same location as the EDMX, you can add a new Class file that has the same signature.

public partial class Customer
{
    // Here are the methods, properties, etc. created by you.
}

When the project is compiled these two classes will become one class in the compiled code. Now, when you change your EDMX, yes it should map correctly, but this is not always the case as EF has be known to be very buggy (suppose to be fixed with EF 4.1 in MVC 3), you can simply change the class name to match whatever it is in the EDMX and "Voila!" you have transferred all custom added code for the class to the new entity object. This is essentially your "class wrapper".

That all depends on the level of abstraction you want to use in your application and needs of presentation layer. Both approaches are possible.

Your code is probably already tightly coupled to Entity Framework (EntityObject is EF type) and it is also not very well testable (Page.Current is probably static) so discussion about some more advanced architecture approaches and separation of concerns is not needed.

Few observations from your code:

• Context is Disposable!!!
• Renaming anything in your database should not modify your class names. That is the responsibility of EF mapping (EDMX) to correctly map entities to new database names.

If you want to use WCF, then you will probably need to create clear POCOs to avoid a lot of issues.

If you want your controllers/viewmodels/pages/whatever to be unit testable, then you will need to abstract your EntityContext in repository interfaces+classes (see repository pattern).

If you just want to make a quick and simple non-testable application, then you don't need to bother about it. Don't forget to dispose the data context at the end of each request.