I creating a little modular asp.net MVC application. I am using dynamic entity framework for adding a entity model to dbcontext:
i have a category entity and i want to use this entity in different project in one solution. when i running application i see this error:
The type 'Module.Pages.Models.Category' and the type 'Module.Menus.Models.Category' both have the same simple name of 'Category' and so cannot be used in the same model. All types in a given model must have unique simple names. Use 'NotMappedAttribute' or call Ignore in the Code First fluent API to explicitly exclude a property or type from the model
Related
I'm currently working on a OData Service(SAP Gateway), wherein the entity types are generated during the runtime. I know, that this wouldn't be as per the OData best practices, where the entity types should be static and is part of the design phase.
Questions:
1. With the request for metadata, all the entity types are generated in a method called DEFINE(provided by SAP Gateway framework). I'd like to separate the generation of each entity type, as the information required for the generation is different for each entity type. Later on, new entity types will be added, which would have a further set of instructions for the generation.
Is the Strategy pattern best for this? With this, the generation of different entity types are separated. If Strategy, then, should the Factory method return all the concrete strategies at once and let the context loop through all the strategies to generate the entity types?
Or is there any other design approach for this?
Thanks a lot in advance!
The entity types are defined in method DEFINE. The definition is nothing but creation of entity type based on a defined data structure. The code required to create entity types varies for each entity type. With runtime, I mean, the code written as the definition of entity type, is executed to form an entity type during the request for metada.
First of all I want to ask that what is the difference between Entity Class and our Model Class ?
And when I use to add Data Annotations on the Entity Classes generated by the Entity Framework in Database approach, it's vanished upon every "Update From Database", and for this user defined Model Classes can be used but I have no idea to use them with the generated Entity Classes.
An entity class is a class that directly associate's with a real object and is linked to business logic and holding information about the system. Entities are usually used to establish a mapping between an object and to a table in the database.
Models are simply classes that are associated with a views and controllers which define or contains the definition of an object and when there has been a change in state. These can hold your data annotations to validate before going up to the Business/Data Access layers...
This leads me on to your next question and if using EF to generate your data model classes using the "database first" approach, then you cannot apply the data annotation attributes directly to your classes. Because the EF Designer generates the model classes, any changes you make to the model classes will get overwritten as you have been experiencing. If you want to use the validators with the classes generated by EF then you need to create meta data classes: http://blogs.microsoft.co.il/blogs/gilf/archive/2011/01/20/adding-metadata-to-entities-in-the-data-model.aspx
Hope that helps.
Danny
I'm building an application using MVC 3 and Entity Framework 4.
I've created my Entity Data Model and generated a database from it.
Now I know the validation attributes such as [Required] or [StringLength(5)] can be used on the model properties to provide validation both clientside and serverside.
I would like to know if these attributes can also be generated dynamically instead of having to add them to the model explicitly? I saw that in EF 4.1 RC you can make use of the Fluent API to further configure your model in the OnModelCreating method by using the DbModelBuilder class.
As shown here
I'm working with a framework however that still uses ObjectContext instead of DbContext so I would like to know if the above solution can be used in combination with ObjectContext?
As a final note, since I've been trying to figure out how to generate and use data annotations it seems using view models would increase the complexity of validation. From what I read here it seems that just passing the models directly to the view would remove the need to add annotations to the models as well as the view models. However that means that you can no longer use strongly typed views when you do joins on the models and pass those to the view directly?
No it can't. Fluent API is different approach to describe mapping. You can use fluent API or EDMX (Entity Data Model). Not both. Fluent API also works only with DbContext API. If you want to have annotations generated you can try to modify T4 template generating your classes.
I have come across a disturbing issue when using poco classes that are extending base classes.
For example, let say you have a Person poco class that has a strongly typed Car property. You also have a Spouse poco that also uses the Car Property.
Now you want to display "Person Car" and "Spouses Car" in the view using the Display("Name = xxx") attribute. You cant!!! Becareful of this issue if you are not using flat View Models
I really have two questions:
What is the difference between an Entity Framework Entity object and an ADO.NET C# POCO Entity.
Do I have updating a record using a repository correct below?
If you turn off code generation, then add the ADO.NET C# POCO Entity Generator, it provides a nice class representation of your Entity Framework 4 objects. The idea is that (from here):
The POCO Template can be used to generate persistence ignorant entity types
from an Entity Data Model.
However, these objects have the relations between objects as well as a link back to the database. For example, you can pull one out of your repository, alter it, then save changes at the repository or unit of work level, and it saves the content to the database.
So my question is what is different between a native Entity Framework object and these POCOs generated using this tool?
This is what I think when I update a record using a repository. Is this wrong?
Request a POCO from the repository.
The Repository loads the records from the data context, creates a new POCO for each record found, copies the values from the Entity Framework objects to the POCOs, and returns a collection of the new POCOs.
Changes are made to these POCOs outside of the repository, then the POCOs are submitted back to the repository using something like Save(POCO).
The repository loads the matching records from the database and copies the POCO properties to the Entity Framework objects.
One calls Save using either the repository object or unit of work object.
In case of POCO generator the generated entity classes (eg, Employee, Company etc.) don't derive from any special class (hence called Plain Old).
Whereas in case of entityobject generator, the entity classes derive from the special 'EntityObject' class, which provides certain capabilities.
The objective behind having POCO classes is to do away with the DB specific concerns of an entity. Thus keeping our domain model unaware of DB/persistence operations.
POCO means that you have a plain old CLR class which is not polluted by special constructs related to the persistance. Entity objects are derived from EntityObject class and they use a lot of classes and attributes directly related to entity framework. When using EntityObjects you are making your code fully dependent on entity framework.
What you describe in your repository was used in EFv1 to achieve POCO approach. Currently you can use POCOs directly. POCOs don't have any relation to the database. In some scenarios POCOs are dynamically proxied by EF dependent constructs but this happens during runtime so it doesn't pollute your code.
I am using Entity Framework and generating my POCO classes via T4 - these classes inherit from nothing and are very plain and simple (created via template in vs 2010)
I tried using the Metadatatype Attribute so I could create a buddy class but when I did this I no longer was able to see my properties... if I removed the attribute! the properties appeared.
Anyway, searching deeper I found this statement from Microsoft
The associated class must be used with EDM or LINQ-to-SQL models because CLR types cannot mark existing properties with new attributes. If you are working with CLR objects directly, sometimes referred to as Plain Old CLR Object (POCO) types, you can apply the attributes directly to the model
So it appears it doesn't work. Anyway it's difficult for me to insert my Data Annotation on the MODEL itself because it's created via T4 hence if I edit it and then re-run the tool it will remove all my changes.
There is a pretty strong consensus around SO and the MVC blogosphere that you shouldn't annotate your business/crud/domain classes with attributes. Not only is your entire MVC stack becoming dependent upon your business/database classes but you'll quickly end up with multiple context scenarios ( same Model, different validation rules ) that are impossible to validate with just a single model.
Use separate view models for your screens, annotate those.
Based on your comment: "Data Annotation on the MODEL itself because its created via T4 hence"
What I'm trying to say is put your dataannotations on your viewmodels, leave your POCO models alone.