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 data access 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 separate 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 recommended to put my Entity Framework def in this other project?
– Will I be sacrificing certain other MVC features by separating it out in this way? (eg, validation?)
– If I’m heading in the right direction and others agree, are there any other examples or docs out there someone could point me at?
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:
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.