I have two .edmx files each containing different entities, using the same database.
On file one i have my app logic entities, one of them is a table called Report.
On the other file i have infrastructure entities such as User table and some authentication stuff.
I want to add a Navigation property from Report on file one to use User on the other file. Is it possible ? I am used to just drawing an association with the toolbox but I don't see how i can stretch the line from one designer to the other.
It is not possible. You must map User entity again in the EDMX with Report entity but in such case you must be very careful with code generation. If both your EDMX produce entities in the same namespace or if you are using POCOs you must avoid User entity to generate class again - it means modifying code generation template.
EDMX has some limited support for reusing types but it is possible only on conceptual level (database level and mapping level must be shared) and because of that it is possible only if you don't use EF designer and maintain EDMX manually as XML.
Related
I'm Developing ASP.NET MVC Web Application project, and I'm using Entity Framework Database First Approach, So I would like to make validations on generated model classes, I know if i make validations on them directly, then my model validations will be overwritten every time my domain models are regenerated.
So I made a research, and found two approaches to use for this scenario:
1- Using buddy classes (How to add validation to my POCO(template) classes).
2- Using ViewModels and Auto-mapping them to my Entities (Designing an MVC repository using ViewModels
I see some sort of redundant code in these two methods, so, my question is:
Which one of the two approaches is best to flow?
1) This is the correct solution for adding validation metadata for the Entity Framework objects. The validation will be triggered automatically by EF before calling SaveChanges()
2) This is an aproach for creating Data Transfer Objects from your EF objects. You normally do this when you want to return the objects to the client (like in JSON format) - and you don't want to expose all the EF specific properties (like navigation properties, primary keys etc)
I'm working on a static library that will help sync Core Data iOS apps with a remote SQL database. My library relies on a few sync-related attributes that each Core Data entity must have, so I've created a parent entity, SyncObject, that all other entities inherit from. SyncObject is defined in the static library's data model and is included in the resource bundle (how's my terminology?)
When I create a new app that uses this library, I merge the the app's data model with the library's data model and programmatically set all of the app's entities as sub-entities of SyncObject. Remarkably, this all works, but it feels clunky: when auto-generating entity class files, I have to manually change the base class to SyncObject (which is itself a subclass of NSManagedObject) in the .h file, and I can't define relationships between entities in the app's data model and entities in the bundled data model because the Xcode data model editor doesn't know about the entities defined in the external bundle.
Is it possible to make the editor aware of bundled data models? If so, how?
I would strongly recommend against this design. If all entities inherit from a single entity then your entire Core Data SQLite data structure will existing a single table. The performance cost for this is quite simply huge.
It is not possible to make the data modeler aware of the bundled data model.
Update
There is a difference between subclasses and sub-entities. There is nothing wrong with Subclassing. Creating sub-entities, however, is quite different and is designed to solve a different problem. Sub-entities are meant to intentionally combine so entities so that they share a common root and share a common set of properties or relationships. The cost of that is that they also share a common table. Which in the situation that they are intended for is not a significant cost.
The thread you referenced confused subclasses and sub-entities. They are not the same and they do not even need to align.
Trying to have an entire data model be sub-entities of a single parent entity is not the intended use of that feature of Core Data. It will cause horrific performance penalties and eventually stop your application from working. You would be better off working from a different design. For example, you could force them to subclass from your class which then subclasses NSManagedObject and do what you need to do in that subclass. You could further require an attribute to exist in each entity so that you can complete your goal.
mogenerator works in that vein (although it does not require an attribute to exist in the entities). There are also syncing frameworks that work off a similar design. They require that each entity have a unique identifier key, etc.
You could go even further and not necessarily require an attribute but instead require that the subclasses define a unique identifier so that you framework can uniquely identify each instance of an entity. You could then work with that uniqueID without requiring its definition be specific (a string, a number, etc.).
Say I have a Visual studio solution with two projects: one web project, and one data project.
Does it really matter whether I pass the EF object from the data project to the web project, or do I need to explicitly define POCOs in the data project to pass to the web project?
It seems to me that needing to create POCOs instead of simply using EF objects adds yet another thing that needs to be done...and I don't particularly see the purpose.
If you're using Entity Framework 4, the EF objects are POCO objects, and so should be used in any situation where your Model matches your EF object (CRUD operations are the typical ones). However there will more than likely be situations whereby the standard POCO object doesn't encapsulate all of the fields that are needed for a View Model (typical ones I have this with are account pages where you have two password fields) and so you will need to create a Model for the page, which then passes the data into your EF POCO objects.
So if you're using DbContext (which creates POCO objects for you) there is no reason not to use those objects.
It's not a good practice to pass the EF objects directly to the web project. As the state changes occurring in the EF objects can directly reflect on the database. Because of this you should explicitly define POC objects for web project.(we can call this as Data Model or simply Model. The POC object used for retrieving data from the View can be called as View Model. In appropriate situations you can use the same POCO class as a Data Model as well a View Model)
I have an MVC 4 app that I am working on and using the code first implementation except I cheated a bit and created my database first then generated my entity classes (poco) from my database using the EF power tools (reverse engineer). I guess you can say I did database first method but I have no edmx file just the context class and my entity classes (poco)
I have a few projects in the works using MVC and EF with pocos but just the one project I used the tool to generate my pocos from the database.
My question is about the mapping files that get created when I generate my pocos using the tool. What is the purpose of these Map files? I figured the map files are needed when generating the db from the model like with the true code first method, in my case where I am using a tool to generate my model from the database do the map files have any influence on how my app uses the entity classes?
The mapping files are to fluent files help Code First generate the database from your model, as well as help EF create the proper relationships.
They can map properties - things like setting a primary key, max length, data type.
They can also map relationships - set things like foreign keys, and defining relationships that don't follow standard CF naming conventions.
Even though you're not generating your database from the app, CF will use this system to ensure that the database it's pointing to is compatible with your model, and in the case of foreign keys and things setup related properties. For example, if you wanted to name a FK something other than NavigationPropertyId, you would need fluent to tell the engine what property to set in the database.
I have a system written in ASP.Net 2.0 Web Form. The framework that talks to MySQL Server is really cool. It reads all controls inside the server form tag or panel and does CRUD operations on the target table.
When I create the CRUD page, I just need to create the table in database user{id,name,password,createdate} and I just need to use id to be the exact column name in the table. The controls can be input/select/option/chekbox/textarea or even FCK Editor or CK Editor on the page. The framework loops through all the controls inside the Panel and save/edit/delete. If I want to add some new fields, email and mobile, I just need to add two controls on the page and add two more columns in the table. That's it. I don't have to change anything in page.aspx.cs file, Entity Layer, Business Layer or Data Access Layer. It is VERY easy to implement and maintain.
We want to upgrade the system to use ASP.Net 4 MVC3 with Entity Framework CT5. We will rebuild the whole system from the scratch. I was hoping some experts here could give me some pointers. I found the following two options to rebuild the system.
1. Code First
Our new system will do the exactly the same operations as the above framework. It will loop through all Request.Forms data and map them with its associate table in the database and save/update/delete all the data. To do this, view will post the form data, controller will accept the values with the Entity classes and save them to the database via EF. I still need to create ViewModel class to display data on View. If there is any change like adding email and mobile fields to user page, I still need to change three places view, entity(domain class) and ViewModel. I don't have to change anything in database as EF will automatically run ALTER TABLE to add two new fields. I still cannot figure out how to minimize the needs of both entity and viewmodel classes.
2. Database First
I really do not prefer this way but I will if this solution provides more flexible operations. I will create the columns in database, the system will dynamically create the ViewModel(I am still figuring out how to do that) reading all columns in the table, and display data on the page. When the view post data it needs to dynamically create the entity class and save the changes to the database.
EDIT:
Reasons of upgrading the current system.
We want to use the power of new features in .Net 4, Linq, Entity Framework, unobtrusive javascript library, easifer to work with JSON data, Remote Validation(We can use RequireFieldValidator, RegExValidator in current system but they are limited, for eg: validation on input checkboxes and option), duck typing with var and interface.
Our new system will do the exactly the same operations as the above
framework. It will loop through all Request.Forms data and map them
with its associate table in the database and save/update/delete all
the data. To do this, view will post the form data, controller will
accept the values with the Entity classes and save them to the
database via EF.
Someone please slap me if I'm missing something here, but these statements seem contradictory to me. If you want a system that will automatically parse the Request.Forms data and map them directly to a database table, then why would you need to use Entity Framework (or any other kind of middleware) at all? The point of EF, or any ORM, is to create a meaningful collection of conceptual data objects that represent your system's nouns. You then operate on those nouns, affecting their properties or accessing their behaviors, and let the ORM figure out how to map them to the tables + columns.
To answer your question, it sounds like you want the easiest solution, meaning the one where you have to write the least amount of code. If that is a correct assumption, then you might want to go with Database first. You can have EF generate your entity classes, but like you said, you will still have to either manually create viewmodel classes or come up with some kind of AOP (using T4 maybe) to generate these for you. But anytime you give a tool the power to generate something for you, you lose control over it.
I prefer code first / conceptual model first, but I also like to have complete control over everything in the application (aside from infrastructure concerns which can be delegated to tools and frameworks like AutoMapper, EF, T4MVC, etc). Yes, it is more work, because I have to create the entity classes, the viewmodel classes, and the views, (and controllers, and action filters, and html helpers, and rrrvrything else). If your domain is one where you can just map text boxes straight to database tables & columns, then maybe this would be overkill for you.