Assume i have a big entity and want to create a typical CRUD application. A user shouldn't have the ability to save some fields of my entity.
So i see two ways to implement change-save logic:
a)
Get entity from DB
Out to page with all fields(fields which user shoudnt change outed as hidden inputs)
Take entity by post method
Attach to context and save
In this case i need to out on page useless fields. And it is sucks no doubt.
b)
Get entity from DB
Out to page only necessary fields(fields which user can change)
Take entity by post method
Get entity from DB
Fill DB entity by new values and save
In this case i need to do additional query to DB. So it is not good for perfomance.
What is right way?
or C):
Get entity from DB
Map entity to ViewModel with only the allowed fields
Post ViewModel with data back to controller
Map ViewModel back to Entity
Attach and Save.
EDIT:
I highly recommend AutoMapper for the mapping to and fro
Interestingly enough, I just watched a video made by Julie Lerman in which she discusses almost the exact same problem. Neither of your solutions was what she went with:
Have a separate entity class that contains the fields that you want to go on the screen, but still maps to the same table that the regular one does. Then just query that DbSet for grabbing the entity (with only those fields), and save the updates to that.
She mentioned this while discussing implementing Domain Driven Design on top of Entity Framework. So that if you have different DbContexts for different functions in your application, you can still have a DbContext that you're using write to the table, but you can restrict which fields that context can write to.
It is recommended to use different ViewModels for different tasks. If you want to show the user some fields of the Model to edit, then you can do so using EditModel and while saving use CreateModel to create and populate the database. This way you can avoid your database structure to be known to the user, thus ensuring protection and security.
Related
I have to create an application that will copy common configuration settings from one database to another database (same schema). I'm wondering if I can use one Entity Model to access both databases. Say it is stores and products that need to be copied. Can I use the same model to get a store from serverA.databaseA and then insert into server.databaseB?
You can have two similar DbSets in two different DbContext classes. As mentioned in comments, the real problem is to deal with identity columns and IMO with context attachments. I think best way is to handle identity columns manually and fetch data from db in a detached state.
Suppose I have a table with whole bunch of fields and an EF entity generated for it. Suppose I want to show an edit form for this entity, BUT with an extra field that doesn't directly map to the table.
So I create a model class that inherits my entity class and my field to it. So far so good.
The issue is that now I have to copy every single field from the entity object to the model object when returning a view and the other way around when saving data. Surely there is a cleaner way to do this?
Specific example would be a user administration form and extra fields would be password and confirm password fields, which are stored in the Membership table.
It's good practice to separate between data-transfer objects used for communicating between application tiers such as UI, and raw entities connected to the storage. Yes, you'll need to copy fields back and forth, but there are tools that can help you with this task, such as AutoMapper.
You can make the EF entity partial (I think they usually are by default), and then add the field in a separate file which also has a partial class for that class. It's not as good practice as Ilya's answer, but it's easy.
In C# is it possible to create a model of entities regardless of the database initially. Are there tools to create graphic entities in this way? What do you recommend?
Well, it's in your question as a tag - entity framework is a good tool for this. You can create classes, that you push later to the database.
Search for "code-first". Google will provide plenty of results I'm sure.
Edit based on the comment:
Well, in that case, try this: when you're creating edmx file, pick the second option - empty model.
From its description:
Creates an empty model as a starting point for visually designing a
conceptual model from the toolbox. Classes are generated from the
model when the project is compiled. You can specify a database
connection later to map the conceptual model to the storage model.
this may be the thing you want then.
I have a table that used throughout an app by Entity. I have a view that returns an identical column set, but is actually a union on itself to try to work around some bad normalization (The app is large and partially out of my hands, this part is unavoidable).
Is it possible to have Entity 4 treat a view that is exactly like a table as the same type, so that I can use this view to populate a collection of the same type? This question seems to indicate it is possible in nhibernatem but I can't find anything like it for entity. It would be an extra bonus of the navigation properties could still be used to Include(), but this is not necessary (I can always manually join).
Since EF works on mappings from objects to database entities this is not directly possible. What you need is something like changing the queried database entity dynamically, and AFAIK this is not possible without manually changing the object context.
For sure the EF runtime won't care as long as it can treat the view as if it was completely separate table. The two possible challenges that I forsee are:
Tooling: Our wizard does allow you to select views when doing reverse engineering (i.e. database-first). Definitively if you can use 'code first against an existing database' you can just pretend that the view is just a table, but you won't get any help scripting the database creation or migrations.
Updates: in general you can perform updates for a view setting up store procedure mapping (which is available in the EF Designer from v1 or in Code First starting in EF6). You might also be able to make your view updatable directly or using instead off triggers (see "Updatable Views" here for more details). If I remember correctly the SQL generated by EF to retrieve database generated values (e.g. for identity columns) is not compatible in some cases with instead-off triggers. Yet another alternative is to have your application treat the view as read-only and perform all updates through the actual table, which you would map as a separate entity. Keep in in mind that in-memory entities for the view and the original table will not be kept in sync.
Hope this helps!
I want to implement a sort of preview mechanism for my application. I have few different models that can be edited. On the edit page's I would like to provide a preview button that would put the edited model into session.
I am thinking maybe I could extend the ObjectSet properties to have it run queries through my in session objects on top of the regular objects in the database. I dont know if that is actually possible, but can anyone think of a way to make something like this happen?
It sounds like you would need a Repository / Unit of work layer that is independent of where the data is coming from, in the "Session" case it could come from in-memory objects stored in the current session, in the regular case from your DB Entity context. You could then pass in the actual data store handling (in memory or DB) as a dependency.
There are many samples around that do work with EF, mostly for the sake of unit testing w/o having to touch the DB:
Testability and Entity Framework 4.0
Creating a Generic Entity Framework 4.0 Repository
Entity Framework 4 POCO, Repository and Specification Pattern