MVC 2 and Entity Framework - Should I put Entity classed in seperate layer?

Question

I'm looking at ASP.NET MVC 2 and Entity Framework for a project I'm beginning. Whilst I previously used .NET lots up until around the time 3.5 had just come out, I've not really been so inspired to keep up over the last few years, so am a bit out of the loop.

Anyway - I'm trying to find some information on preferred solution setup when using MVC 2 and Entity Framework, and it would seem most intuitive to me to set this web app up in 3 layers:

MyProject.Web (MVC project for presentation) MyProject.Data (Data gateway layer using Entity Framework to speak to the DB) MyProject.Tests (Test project as created when setting up a new MVC project)

This seems to be contrary to the examples I'm finding, and the documentation (eg, the NerdDinner example) which see the MVC project as mediating directly with the database. The NerdDinner example puts the dataaccess in a repository class mixed in with the MVC models.

I've tried going with the way which seems best to me, and have created my "ADO.NET Entity Data Model" item in my seperate Data project, but this gives me an error when I try to use MVC to list the items in it ("Unable to load the specified metadata resource.") unless I have a copy of the Entity Data model in my MVC project as well.

Before I go too far down the road of looking into this error, I want to find out if I'm just fighting against the framework for purism when I could just be disciplined with only using data access in my repository.

so: - Is it even possible or recomended to put my Entity Framework def in this other project? - Will I be sacrificing certain other MVC features by seperating it out in this way? (eg, validation?) - If I'm heading in the right direciton and others agree, are there any other examples or docs out there someone could point me at?

Thanks loads!

Answer 1

Yes, I think it's a good idea to put your entities in a separate assembly.

One way to fix the "Unable to load the specified metadata resource" error is to specify the assembly in the connection string explicitly:

<connectionStrings>
    <add name="MyEntities" connectionString="metadata=res://*/AssemblyName.bin.Namespace.MyEntities.csdl|res://*/AssemblyName.bin.Namespace.MyEntities.ssdl|res://*/AssemblyName.bin.Namespace.MyEntities.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=SERVER_NAME;Initial Catalog=DBName;Integrated Security=True;MultipleActiveResultSets=True&quot;" providerName="System.Data.EntityClient"/>
</connectionStrings>

Note, especially, the AssemblyName.bin.Namespace.MyEntities. This is the assembly-qualified resource name (assuming the assembly is called "AssemblyName.dll". You may need to use Reflector to figure it out the first time you do this.

This answer might also be helpful.

Answer 2

It is certainly possible to put your Entity Framework definition in another project. Personally, I keep it in another project if the data layer will need to be shared by multiple interfaces (MVC, WCF, WPF).

Take a look at these two MSDN articles on building and using an EntityConnection.

Build an EntityConnection

Use EntityConnection with an Object Context