The Developer documentation makes reference to Parent Entity when creating an entity. Has this feature been deprecated?
Also, the what are Packages in Slingr? There's no reference to it in the user documentation either.
Thanks
Kevin
The Parent Entity is a feature that is still in beta for some apps, it is not publicly available. This is used for inheritance.
Packages allow to organize your entities. This is helpful when your app starts to grow and you have many entities. Think them as packages in Java, which are used to organize your classes.
Related
Previously I asked this question and on a answer I got this comment:
This works, however injecting the container to a part, as far as I know, is not a "normal" use-case of MEF.
In my web app I have a few repositories that, of course, retrieve entities from the DB. To make them as loosely coupled as possible I'm making them return interfaces (eg IUser, IBill, IBlaBlaBla...) and the repository project only references the library project (that contains the interfaces). I use MEF composition capabilities to tie it all up...
Since the repository must have a concrete object to fill with info it got from the DB and the only the Container is aware of which concrete class maps to a specific interface I think that the repository MUST have reference to the container so it can call the "Resolve()", get a new instance and do his job, but that apparently is a mistake.
Can anyone tell me why and what approach would be better?
PS: I don't know if it's relevant but I'm using DDD...
I think the flaw in your design that lead to this problem is the use of interfaces to hide entities behind. Since entities are your core concept in your domain, there should be no use in hiding them behind an abstraction. Let's put it differently: do you ever have a different implementation of IUser?
In other words, ditch the IUser, IBill, etc. interface and let your repositories and business commands depend directly on your aggregate entities.
I'm building REST API for my system with complex entities that have many relationship with each other. I'm looking for a way to automatically return entities with one-to-many or many-to-many relationship or I have to do it by hand. Any suggestion? Thanks for your help
JMS/Serializer can serialize retations if you set Array or ArrayCollection type. You can install it with php composer.phar require jms/serializer-bundle. Read more at documentation.
If you want an Hateoas architecture, you can use FSCHateoasBundle (which hooks the JMSSerializer).
You can set relations using annotation and embed resources as the property of the main resource.
This bundle will automatically add navigation links to these resources.
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.
I have started working on a new project and am switching from LinqToSQL to EF 4.1 as my ORM.
I already have a database set up to work with and so am going with the database first approach. By default the EF generates a context which extends ObjectContext. I wanted to know if a good approach would be to replace it with DbContext.
Most of the available examples deal with only Code First and DbContextbut DBContext can be used with Database First too. Are there any advantages I get by using the DBContext? From what I have read the DBContext is a simplified version of the ObjectContext and makes it easier to work with. Are there any other advantages or disadvantages?
You will not replace anything manually. You will need DbContext T4 Generator available at VS Gallery. Don't touch your autogenerated files - your changes will be lost every time you modify EDMX file.
I answered similar question last year. Now my answer is mostly - for new users DbContext API is probably better. DbContext API is simplified - both in terms of usage and features but you can still get ObjectContext from DbContext and use features available only in ObjectContext API. On the other hand DbContext API has some additional performance impact and additional layer of bugs. In simple project you will probably not find any disadvantage in DbContext API - you will not see performance impact, you will not use corner features available only in ObjectContext and you will not be affected by occasional bugs.
A lot of information and blog posts was collected since DbContext API was released so you don't have to be afraid that you will not find description of the API. Also ADO.NET team now uses DbContext API as their flag ship.
I'm not a big fan of DbContext API but my opinion is not related to its functionality but to its existence - there is no need to have two APIs and split development capacity of ADO.NET team to maintain and fix two APIs doing the same. It only means that there is less capacity for implementation of really new features.
I'm using it now with Oracle on an add on to an existing application. The simplification that Ladislav refers to works well for me on this project as I am short on time and resources. I have not found any gotchas as long as you stick to simple CRUD operations and less than ~150 tables.
You can still use metadata annotations to provide basic validation and localization and there is enough documentation out there but you won't find much on official Microsoft sites.
I have a model library (namespace Test.App.Model.EF) with the Entity Framework implementation in it. This has all of the entities provided in the EF designer for me which I want to use. Within this Model.EF implementation, I have several repository classes. I want to create interfaces for these classes and place them in a seperate interface library (Test.App.Model.Interface). So I do so, obviously the implementation library needs a reference the interfaces. BUT, I notice that the interfaces need to know about the objects in the EF designer (since I want to reuse them). I can't create a reference from the interface library to the ef implementation because then I'll have a circular reference.
So, as I write this, I'm coming to the conclusion that I'll probably need a Test.App.Entities.EF that has the Entity Framework "created" entities. That way my interfaces lib could reference without having to know about the Model.EF.
Does that sound like the way to go?
Ok, so after much wrestling with this, I found the buzz term that describes the situation. What I'm looking for here is called "Persistence Ignorance". This is what would make what I described in my thread happen. Well the Entity Framework that we use (not 4.0) does not support this yet (unless you go homegrown like done here).
With having that said, EF 4.0 will have this feature but from what I understand, it's coupled with .NET 4.0 (why it's called EF 4.0 in the first place) and that's not going on our production servers anytime soon. Since we've decided to go with this technology, our repository abstraction to interfaces will be placed on hold until upgrading to 4.0 is a viable option.
Let this be a caveat for those seeking the same information. Please also let me know if this sounds incorrect (because I would love to make this happen sooner then later but I don't want my team jumping through hoops when a later implementation will remedy the issue). Thanks all!