For a business application, I am providing a base entity model. Thereafter the end user should be able to extend the model for his specific needs.
For the base model I want to use database-first approach. But I don't know how to accommodate for allowing user to extend it.
One part is to provide a UI for entity model editing and the other is to reflect the changes in the model and database thereafter. Please offer suggestions.
EDIT:
- Once the entity model is edited and saved, all EF facilities should work like before.
- Model update is conducted at the time of maintenance, i.e., it is not in use by business users.
- The affected project can be compiled and a new assembly can be produced and put to use.
It is not possible. When you modify entity model you must modify related entity classes (or create new ones) => you must recompile application or use some dynamic assemblies. Moreover there is no API to modify entity mapping at runtime so you are going to build new Entity designer.
It is generally same requirement as installing C# 2010 Express on client desktops and allowing them to modify, rebuild and redeploy your application.
Edit:
What you want requires:
Modifing EDMX - very complex XML file. Writing custom tool for that will be complex task. Moreover you will have to add logic wich will don't allow user to break the application.
Running T4 templates to generate new or modified entities.
Compiling application - what if user makes changes which break the build???
Redeploying DB - this itself is pretty bad taks because whole DB generation logic is Workflow running in Visual studio. Moreover you need another workflow which will be able to upgrade database - default one can only deploy new blank DB. Such workflow exists but it requires VS 2010 Premium or Ultimate.
Related
Bit of a noob question I'm afraid. I have an ASP.NET Core Web Application, which uses Individual User Account for authentication so it's brought in the Identity bits and created me migrations and an "ApplicationDbContext" for all of the user/roles stuff. I moved the Data related classes, migrations etc into a separate class project to separate it from the MVC project, but other than that it's out-of-the-box. All good. My DB has been created by migrations and I can register and login.
Now, I'm coming to build my app, and I'm not sure where is best to add my entities. The question is should I
1) Add my entities to the "ApplicationDbContext" which was created for me by Visual Studio?
2) Create a second DbContext instance in my Data project?
3) Something else?
I understand that if my app was to use separate databases for authentication and domain data then it would be a no brainer and option 2 would be the answer. But this app is very simple with one database, so I'm wondering if I may be able to get away with option 1.
The ApplicationDbContext that was created for me inherits from IdentityDbContext. I don't know if that has other implications if I were to go with option 1 and add my entities to ApplicationDbContext.
I did start down the road of option 2, but quickly found that things like Add-Migration wouldn't work when the project had 2 contexts. I found that the Add-Migration command now has a -context switch which can be used to tell the command which context to use, but I'm a bit concerned that I will run into other issues. Particularly I am going to be using VS Team Services to build and deploy the app to Azure using continuous deployment, and I don't know if those build and release features will cope with the multiple DB contexts.
Any advice from somebody in the know? This has got to be a pretty standard requirement, right?
Hence your app is very simple one,you can use ApplicationDbContext for your domain models as well.That means, I would like to recommend you to use single context class for your app.If you do so,you can easily manage your business requirements (i.e. any relations between your classes) with the users and Roles on the IdentityDbContext context.
We are currently rewriting an existing internal ASP.NET Web Forms application. Our application consists of a Web Api back end which uses Entity Framework 6 for data access and an front end which uses AngularJS.
We have an existing large database that I've created EF models using the Code-First Using Existing Database method and we are using data transfer object classes as inputs/outputs to our API methods so we aren't directly exposing our model classes. So basically, I'm trying to become proficient with EF, Web Api and AngularJS all at the same time. For the most part I'm fairly comfortable with the latter two, but for EF I haven't completely gotten comfortable with. I've watched a lot of the videos on Microsoft Virtual Academy but this is the first time I've had some hands-on experience with it.
We've been working on this application for a few months and so far we've only had to work with CRUD operations on our entities (POCO DTO's) which are flat objects with simple properties. However, we've finally come across some situations where we need to deal not only with our classes, but properties which are classes themselves; a parent-child relationship.
Therefore, I have the following questions:
I see that when we have a proper foreign key relationship in our DB, that virtual properties are created in EF, which from what I recall are to support lazy-loading. However, lazy-loading isn't really feasible in this environment where we are using web services (Web Api). Our object model does allow for some really large hierarchy of classes where a fully populated object and its children would mean a large amount of data would be passed around when that really isn't necessary, so in most cases a first level object is all we need. In some cases however, we do want to populate child classes, so my question is how do we do that, and where do we do that? I've looked at the automatically-generated code in the DB Context but we have also used scaffolded code to create our controllers. Which place do we need to do this? I've seen code samples showing how do to this but it hasn't said specifically where this code lies. It appears to be within a controller but I could be wrong.
If we do allow for 2- or more level hierarchy of objects, does EF automatically handle operations (updates, deletes, etc.) -- for example, if we have a "Company" object which has a collection of "Customer" objects, and we delete the "Company" object, do the related "Customer" objects get deleted too? Also, is a multi-step operation like that automatically performed within a transaction or do we need to explicitly set that up?
If I modify a model class or the DB context, seeing as this code is automatically-generated, that's generally bad practice as my changes could be overwritten, so I am assuming the controller code is where I want to make my changes. I am aware of database migrations but I have no experience with them and I am sure I'll need to use them at some point because I am fairly confident that our database may not have all the foreign key relationships necessary for EF to do everything we need at the moment.
I know this is a long post, but if anyone can give some guidance on how to do some of these things because it's not only me that's having to deal with this but I have two other developers on my team who are working on this project and we are all as inexperienced with this as the others are. Thanks
For the purpose of sending data across a web service, I'd suggest creating a DTO to hold the data you want to send and mapping your entities to the DTO instead of trying to send the entities themselves in your payload. It also protects your API from changes to your entity.
Cascading deletes are configurable, iirc, but I'm not 100% sure what the default is. Transactions are generally not implicit, so you will want to use those where you require them.
Not exactly sure what you are asking here. In general, how your entities/tables change depends on if you are using database-first or code-first. If you are using database-first (you will have a .edmx file in your solution that has the model matching your schema), you just update the SQL directly and update your entity model via the .edmx. If you use code-first, you will change the entities how you want them and run a database migration to update your database to match.
MSDN article about code-first migration: https://msdn.microsoft.com/en-us/data/jj591621.aspx
What I'd LIKE to do is manipulate EF to support plugins that access a shared database. So the database would contain all of the tables for the main application plus all of the tables required for each plugin. As the application doesn't know anything about the plugin data structures, it cannot be responsible for their management. The plugins are solely responsible, and create the tables themselves. However, the plugins know about the host application and its data structures, so ideally should be able to reference them and even inherit from them, resulting in a database that is extensible yet able to implement optimized patterns.
In EF, this translates to a HostContext that contains the DbSets appropriate for the Host. Each Plugin, I thought, should have a PluginContext that inherits from HostContext that contains the DbSets needed by the plugin. The entity classes included in PluginContext would then be able to reference HostContext entities, and/or inherit from those entities, and EF would be able to resolve the table mapping and relationships.
I'm using EF6. When I attempt the above and try to list the single entity I've included in the PluginContext, an exception is thrown complaining that the entity doesn't exist. Sure enough, no matching table has been created.
Is what I'm attempting to do supported by EF? If so, what am I doing wrong?
As I mentioned here: EF6 Empty Model target string
I began this effort using Rowan Miller's example here: http://romiller.com/2013/02/15/extending-and-customizing-code-first-models-part-2-of-2/
In the end, I abandoned that approach, for a few reasons: 1) I couldn't get it to work (I can't remember exactly why but I do suspect it was related to differences in EF since the article was written), and 2) I didn't like the need to write manual migrations.
I ended up with PluginContexts that inherit from HostContext, as I had hoped, and am able to reference and even inherit from host entities. This has restrictions in its use though:
My plugin logic is completely self contained. I have no need for the host application to manipulate or create plugin entities. Therefore, I am not trying to get the system to subsitute any plugin entities for host entities. If construction of a particular entity subclass is required, then a plugin method must be provided for that and an inheritence hiearchy will be utilized.
Migrations can be built even on the plugin context as per normal. However, that migration may easily include migration code from the Host Context. So I have to remember to look for and remove these instructions. This is typically very straightforward and I believe is much less effort than building the equivalent from scratch.
If there is any change to the Host Context then this must be reflected in every Plugin Context. Basically, this means anytime a new migration is created to reflect changes in Host Context, migrations must be created for each plugin as well, even though that migration may be empty (it isn't really - the critical part here is updating the Model in the latest MigrationHistory record to reflect the Plugin model that has been changed because of the inherited Host model).
This approach is being used to extend an in-house application with in-house plugins, and so may not be as easy to adopt in other scenarios which Rowan's solution is probably better suited.
Is there a template or tool to generate code from the database directly? I want to use model first scenario but do not want .edmx file for mappings. There is a database with many tables and I do not want to write all the classes (I am lazy) for that. So, is there a template to generate the code and set the annotations/use fluent api for defining the relationships, etc automatically from the existing database?
This would be helpful in the following scenario as well. Say, I was using .edmx with POCOs and now I do not want the mappings in the .edmx file. I want the mappings in the code. It would be great to have a tool or a template to generate the mappings in the code from the existing database.
I am starting on learning EF 4.1. I think "Code first becomes model first in version 2 i.e. after the database is created/released (in version 1) and needs some changes". Is that really true? I'd love to hear some comments. Thanks.
Check out the 'Reverse Engineer Code First' feature of the EF Power Tools CTP1 that was just released.
For generating classes, you can use POCO t4 template generation. Have a look at this detailed link which will help you getting started. That way you will get all the classes generated.
For mapping, you can use Code-Only style for Entity Framework but generating classes and context using POCO template will have far more advantage over creating the mapping yourself. Imagine adding new tables or modifying the tables, it will involve more work. But I will certainly love to know if there is any mapping tool for that.
It is possible that you are using EF-provider Devart dotConnect for Oracle when working with Oracle database. In this case the following information will help you to choose the tool.
The first version of Entity Framework Power Tools also contained the capability of generating a Code-First model with fluent mapping from an existing database. Although useful, this functionality is limited as regards its flexibility: the developer can only set the connection string; following that, classes are generated from all database objects available to the user. That is not extremely convenient, since in Oracle, for example, numerous schemas containing hundreds and sometimes thousands of tables are available to the user.
Rather than resort to this limited functionality, the users of Devart ADO.NET providers can avail themselves of impressively robust design-time development capabilities of Entity Developer, an EF-designer delivered with Devart providers. Also possible is the choice between the Database-First approach, as provided in EF Power Tools, and the Model-First approach, within which Code-First classes are created in the EDM-designer.
When compared to EF Power Tools, the Database-First approach to the development of EF Code-First models also allows selecting objects that must be available in the model, setting naming rules for the generation of class names and properties and so on. Besides, the resulting model can be modified and improved in the designer.
To better meet developers' needs, Code-First code generation in Entity Developer both for C# and VB is based on the T4-template that is easily accessible and can be modified in feature-rich T4 Editor contained in Entity Developer.
For more information on Code-First development in Entity Developer, see "Entity Developer – EF Code First DbContext Template"
http://www.devart.com/blogs/dotconnect/index.php/entity-developer-ef-code-first-dbcontext-template.html
I've been using the entity framework in combination with the self tracking entity code generation templates for my latest silverlight to WCF application. It's the first time I've used the entity framework in a real project and my hope was that I would save myself a lot of time and effort by being able to automatically update the whole data access layer of my project when my database schema changed.
Happily I've found that to be the case, updating my database schema by adding a new table, changing column names, adding new columns etc. etc. can be propagated to my business object classes by using the update from database option on the entity framework model.
Where I'm hurting is the CRUD operations within my WCF service in response to actions on my Silverlight client. I use the same self tracking entity framework business objects in my Silverlight app but I find I'm continually having to fight against problems such as foreign key associations not being handled correctly when updating an object or the change tracker getting confused about the state of an object at the Silverlight end and the data access operation within the WCF layer throwing a wobbly.
It's got to a point where I have now spent more time dealing with this quirks than I have on my previous project where I used Linq-to-SQL as the starting point for rolling my own business objects.
Is it just me being hopeless or is the self tracking entities approach something that should be avoided until it's more mature?
What version of self tracking entities are you using?
I'm using the .Net 4.0 version together with visual studio 2010. All CRUD operations work fine, also operation with FK.
I had problems in VS 2008 with FK but that's gone in VS 2010 with .Net 4.0.
If you want, I can provide you some samples.
Greetings
Since STE entity does not support lazy loading you should use Include on the server side include related properties. There is no way to include all related navigation properties. You have to explicitly include the properties. for instance
//server side
customer.Include("Orders.OrderDetails").Include("Address")