I am building an ASP.Net MVC 3 web application using Entity Framework 4.1 with the Database First Approach.
I have just setup my solution with separate projects for the following:
UI - MVC app
Model - Class Library
POCOs - Class Library
Repositories - Class Library
Services - Class Library
I have set this up a few times before without any trouble, but now when I try to create a controller in my MVC app, I get the following error:
Unable to retrieve metadata for 'Entityname'. An item with the same key has already been added.
This happens when I try to add any controller with an Entity for its Model class. I am stumped with this. I tried re-creating the model from the db and regenerated my POCO classes, but still this problem exists.
Can anyone please help?
Thanks.
I solved it. When Entity Framework created my entity data model, some of the names it gave to the navigation properties were a bit meaningless. I therefore edited a couple of these properties, however, I ended up naming two different navigation properties, with the same type of association, the same name. Needless to say EF didn't like this. I renamed the offending navigation property. It was a tough one to fix as there were no compile errors from the model.
Related
I have a web application with n-tier architecture. All the POCO classes are in a class-library project named EntityFramework and the DBContext class named DB. And another project is WebAPI with all the API controllers. I added the following code in my WebAPI controller:
using EntityFramework;
namespace WebAPI
{
private DB db = new DB();
}
Although I have added the reference of EntityFramework in WebAPI but still the line 'using EntityFramework;' has the red wavy underline and DB object cannot be created.
First of all read what the error message is saying and put it in your Post.
There could be a number of issues that cause that. A couple guesses from me:
You now have 2 dlls called EntityFramework and the code does not know which one you want to reference, hence the error.
the version of the dll does not match where you reference it. So, check both projects and make sure they both target the same framework version.
Do not call your DTO library EntityFramework, chances are you will get issues with the actual EntityFramework dll. Call it DTOs or Models, or anything else.
I have a MVC3 project that is referencing a WCF web service....and that WCF service references a data class library.
When I try to scaffold a controller, I have the option to select a Model class from a drop-down.
I would expect to see the data classes that are defined in my data class library, but they're are none there. I'm puzzled by this. I thought that because the MVC project is referencing a WCF service that is referencing the data class library that the classes would be available to choose from.
Am I missing something?
I had what sounds like the same problem. Take a look at this answer and verify you don't have the exact same thing happening Attempting to add a strongly typed view does not find any classes in the MVC project
(I had a hard time titling the question so feel free to suggest edits)
Here's the situation: we have just started building a system which is comprised of two integrated MVC 3 web applications running on Azure with a shared AzureSQL database. There are many reasons for running two apps instead of one and I'd rather not get into that...
Originally, database was created code-first from the MVC application "A". 75% of entities from all created will be relevant to application "B" plus application "B" will need a few entities specific to it.
Currently, the entities-defining classes have been extracted into a class library so within the application "A" solution to allow for reuse in application "B". But I am still unsure how to go about adding entities required for application "B"...
The question is: what is the best way to manage the database development/management in this situation? Specifically, where should the definition of entities be? Should we just have a separate db project defining the database and work db-first? (with this option being my preferred at this stage).
Since both of the devs (me and the other dev) working on this are new to MVC and EF, any advice would be much appreciated.
Without seeing what you have its not entirely mapping here in my brain - but I think I may have an idea on this.
Can you create an additional projects containing your models (data access layer) that has your entity framework edmx (or code first) and poco templates installed. This project will be shared by both applications - ie both projects get this assembly and both have the ef connect string in their web.configs.
Another approach is to put all code first into a single project (whatever.domain, whatever.models) etc. Your mapping code then goes into your DataAccess project
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Conventions.Remove();
modelBuilder.Configurations.Add(new CustomerMap());
...
}
You now have shared poco classes and a single data access layer.
Some treat their poco classes as their domain objects (theres no problem with this) and their business logic goes in the poco classes. This is fine as long as your poco objects themselves remain persistent ignorant and ideally you don't want to reference implementation specific components in your poco classes. For a good writeup here see:
POCO - if POCO means pure .net class with only properties, where i can write validations in MVC
Personally I like db first and then reverse engineer it using the EF power tools to have a code first model as if you ever want to integration test it, you can simply create the db for your integration tests and remove it when done.
I will start to code a new Web application soon. The application will be built using ASP.Net MVC 3 and Entity Framework 4.1 (Database First approach). Instead of using the default EntityObject classes, I will create POCO classes using the ADO.NET POCO Entity Generator.
When I create POCOs using this tool, it automatically adds the Virtual keyword to all properties for change tracking and navigation properties for lazy loading.
I have however read and seen from demonstrations, that Julie Lerman (EF Guru!) seems to turn off lazy loading and also modifies her POCO template so that the Virtual keyword is removed from her POCO classes. Julie states the reason why she does this is because she is writing applications for WCF services and using the Virtual keyword with this causes a Serialization issue. She says, as an object is getting serialized, the serializer is touching the navigation properties which then triggers lazy loading, and before you know it you are pulling the whole database across the wire.
I think Julie was perhaps exagarating when she said this could pull the whole database across the wire, however, even so, this thought scares me!
My question is (finally), should I also remove the Virtual keyword from my POCO classes for my MVC application and use DectectChanges for my change tracking and Eager Loading to request navigation properties.
Your help with this would be greatly appreciated.
Thanks as ever.
Serialization can indeed trigger lazy loading because the getter of the navigation property doesn't have a way to detect if the caller is the serializer or user code.
This is not the only issue: whether you have virtual navigation properties or all properties as virtual EF will create a proxy type at runtime for your entities, therefore entity instances the serializer will have to deal with at runtime will typically be of a type different from the one you defined.
Julie's recommendations are the simplest and most reasonable way to deal with the issues, but if you still want to work with the capabilities of proxies most of the time and only sometimes serialize them with WCF, there are other workarounds available:
You can use a DataContractResolver to map the proxy types to be serialized as the original types
You can also turn off lazy loading only when you are about to serialize a graph
More details are contained in this blog post: http://blogs.msdn.com/b/adonet/archive/2010/01/05/poco-proxies-part-2-serializing-poco-proxies.aspx
Besides this, my recommendation would be that you use the DbContext template and not the POCO template. DbContext is the new API we released as part of EF 4.1 with the goal of providing greater productivity. It has several advantages like the fact that it will automatically perform DetectChanges so that you won't need in general to care about calling the method yourself. Also the POCO entities we generate for DbContext are simpler than the ones that we generate with the POCO templates. You should be able to find lots of MVC exampels using DbContext.
Well it depends on your need, if you are going to serialize your POCO classes than yes you should remove them (For example: when using WCF services or basically anything that will serialize your entire object). But if you are just building a web app that needs to access your classes than I would leave them in your classes as you control the objects that you will access in your classes through your code.
When I add a strongly typed view I see my Entities listed in the Model class dropdown. But, if I select an entity and Scaffold, say List, I get a runtime error of object reference not set to an instance of an object.
In past projects I created a Service layer that called LINQ using CRUD. Then I consumed this service in my Controller and manually created the Views from the resulting service classes. It would be a lot easier if MVC just did all that for me.
Is it possible to directly create scaffold views from concrete classes inheriting EntityObject?
Simple answer : Yes.
I just tried the following test case...
New Project
Create EDMX
Build
Add Controller (With Read/Write actions and views using entity framework
pick Model class and context (the thing normally suffixed with 'entities'
click add
run - it works
EDIT: added MVC Scaffolding too...
open package manager
Install-Package MvcScaffolding
Add Controller (MVC Scaffolding controller With read/write actions & views using EF COde)
Build and Run : Also works.