I'm in the process of looking around at options for a back office tool. On the face of it the tool is simple CRUD so I was immediately attracted to Dynamic Data on top of Entity Framework (we're definitely a Microsoft shop!).
The problem is that future requirement is to support versioning. By this I mean :
User performs a series of updates to a series of entities
When they are happy they submit the changes
Changes persisted to the DB along with enough info to support a rollback
Elsewhere we've got handcrafted app that :
Includes a version id that is incremented as each new row inserted - i.e. we don't update we add a new row
A work item table ties together the changes using the version id along with the entity type (table)
So, the question is, how would I achieve a similar end result using entity framework and dynamic data?
If entity framework, etc isn't appropriate - what would you use (.Net)?
Thanks,
Alan
One solution would be to move the logic for the versioning to database triggers. This way you are able to use a standard Dynamic data on top of Entity Framework, and retrofit versioning by running a set of database scripts.
I would like to mention that in the new Dyanmic Data Preview 3 there is a new feature DomainService which supports Roles based security please see David Ebbo's Serssion from MIX09 here Microsoft ASP.NET 4.0 Data Access: Patterns for Success with Web Forms MIX09-T47F
Related
I am working with sql server and entity framework in a web ASP.Net C# Project. I am working with "Database first" concept. This mean i draw my database structure from sql server management studio on my local development computer. I add fields, rename fields, add table, change type, etc in the life of my project.
What i want to do is to see what to do when i want to apply database structure changes on my production(s) server(s). Is there a way for entity framework to "detect" changes with a concept of migration versioning like in symphony doctrine ? I actually patch by hand by applying sql scripts on my production server.
Thanks
In all cases you need to do some development tasks
Depends on the entity framework model you are using,
Code first approach : then you can use the reverse engineering, you can find this extension online, you can use the Tools > Extensions and Updates to find it , or you can update your classes manually.
Model first approach: then right click inside the edmx and Update Model from database
I have a number of tables inside a database that I use for 4-5 different websites. These tables already exist and have plenty of data and views/stored procedures/functions etc. already completed.
I would like to provide an api to give access to each of these tables to whichever website I happen to be using so they're accessing the data in a consistent manner. I have Visual Studio 2015 and have been trying to create a Web Api using EntityFramework.
However, every tutorial I find for accessing databases insists on creating the database and tables within the code for the api, and utilizes just the tables with the various CRUD actions handled within.
As I have the tables built, I don't want to recreate them, and as I have some programming already in place using functions/stored procs, I don't really want to reinvent the wheel and recreate it all.
I did find this: http://www.c-sharpcorner.com/UploadFile/4b0136/working-with-stored-procedures-using-entity-framework-part/ for EF6 (though I believe I'm using EF7, but that seems to be importing each function in turn, which seems.. kludgy)
So my question is two-fold:
Is ASP.NET 5 web api the right tool for the job?
Can the ASP.NET 5 web api handle stored procedures easily?
At time of writing it's currently easier to build an API over an existing database using ASP.NET 4.6 and EF 6. This tutorial describes how you can go about building a model from an existing database:
http://www.asp.net/mvc/overview/getting-started/database-first-development/creating-the-web-application
Once you have a model and your classes in place, you can then follow any article on scaffolding Web API.
I've done a custom Core Data migration several versions back when doing some structure changes in my app. (So created a new model version, and a mapping model with custom policy class).
Now, I want to do some more changes. So I've created another model version. Now, I'm not sure whether I need to create another mapping model for this change? If I do, will core data just figure out the appropriate one to use based on the users version?
Will I also need to create another custom policy class, or can I somehow add the new logic to the first one?
Lastly, will I need to add any logic for migrating from the original database straight to the current database? Or will core data figure that out for me, and migrate to the median version first, and then to the current version when a user loads an app version with the original data structure?
Thanks!
I guess the answer to whether or not you need to create another mapping model is... it depends. See Apple's docs here (specifically comments on lightweight migration): https://developer.apple.com/library/ios/documentation/cocoa/Conceptual/CoreDataVersioning/Articles/vmMigrationProcess.html#//apple_ref/doc/uid/TP40004399-CH6-SW1
Depending on your model changes, you may use "The Default Migration Process". When calling addPersistentStoreWithType:configuration:URL:options:error:, use the flag NSMigratePersistentStoresAutomaticallyOption.
Also, I'm sure that unfortunately you need one mapping model for each possible migration. If you have 3 models, you'll have to implement: 1 to 3 and 2 to 3. Core Data is not smart enough to do the intermediate steps automatically :(
I'm using Entity Framework 5 model first. Say I've deployed the application and I'd like to upgrade an EF entity with new columns, basically adding columns to the table.
What is the best way to upgrade the existing database without losing data? For example I have a User table that I add two new columns to. If I try to script a schema change the tables will need to be dropped in order to add the new columns. Is there a way to update the tables without needing to recreate them? Thanks!
This may be a late answer but I have had the same problem and could just find one solution, there is an application that can update the model-first generated databases without losing the data.
It can directly open the model file and update the database tables.
It also installs some extensions on Visual Studio that I have not personally used but may be usable.
The name is Entity Developer and there are some editions of the application listed here:
Entity Developer Editions
The free edition is usable only for 10 entities or less that may not suit your needs but the Professional edition is usable for 30 day as a trial that may help you do the job. The only solution I could find on the net was this one.
Hope it helps you with the problem.
How is everyone designing their EF models when using the built in ASP .NET Membership functionality?
I have many entities (blog posts, comments, photos, etc.) which have a user id associated with them. I currently have a User model that maps to the aspnet_User table, but there is lots of sketchy code juggling around both the MembershipUser entity and the User model which I've created.
Does anybody have any clever solutions I may be overlooking to merge the two entities while still using the included membership functionality?
What I have done in this situation is to create a View in SQL Server, which selects from my own User table and joins one or two columns from the ASP.NET tables. I then map my User entity to this View using ToTable() in DbContext.
This works well enough for me; just note that you cannot use an UPDATE statement on a SQL View if it affects columns from more than one table, so the properties from the ASP.NET tables should not be modified via EF (how you enforce this depends on your implementation).