How is it possible to support a GUID and base interface class in different project?

Jan 20, 2014 at 9:19 AM
Edited Jan 20, 2014 at 9:25 AM
Hi,

I have just started playing with BrightStarDB and have a few questions.
1) I have created a base Entity with common properties that all my other entitites inherit from. If I place this class in the same project as my entity, everythign works fine but if I house it in a different assembly, I just get property not implemented - Any ideas how to make this work?
2) One of my properties in the base entity is a GUID. Entity framework does not like this. How is it possible to use a GUID or do you jsut store it as a string?
3) If you define the Id on the base entity, do you also need it on the inherited one?

Many thanks

Mike
Coordinator
Jan 20, 2014 at 12:09 PM
mikip wrote:
Hi,

I have just started playing with BrightStarDB and have a few questions.
1) I have created a base Entity with common properties that all my other entitites inherit from. If I place this class in the same project as my entity, everythign works fine but if I house it in a different assembly, I just get property not implemented - Any ideas how to make this work?
The EF code generation only scans the assembly that the context is defined in. So I'm afraid you have to defined your common entity in the same assembly along with everything else.
2) One of my properties in the base entity is a GUID. Entity framework does not like this. How is it possible to use a GUID or do you jsut store it as a string?
There isn't a natural mapping for GUIDs into RDF datatypes, so that mapping isn't currently supported. I would say just store it as a string, you can use extension methods to convert to/from a GUID, or implement a property on the generated partial classes (although in the latter case it needs to be implemented for each derived class)
3) If you define the Id on the base entity, do you also need it on the inherited one?
If you defined the Id either with an [Identifier] attribute or by using the name Id for the property, then it should be fine to keep just the definition on the base entity. If you deined the Id as a property called {EntityClassName}Id (e.g. BaseEntityId), this might not get picked up by EF (its not something I've tried and I'm not sure I have any unit tests in for this so I can't be 100% sure without trying it out...)
Many thanks

Mike
Jan 25, 2014 at 8:50 PM
Techquila,

I understand the issue with Guid's (I wanted to use them as well, since that's what I use for id's in my SQL server databases.

However, the issue of forcing the entity interfaces to be in the same assembly/namespace as the context is more troublesome to me. That's also one of the reasons that earlier versions of Entity Framework were somewhat of a PITA - the POCO's had to be in the same assembly/namespace as the context.

The most recent versions of EF have 2 .tt files. One for the context, and one for the POCO's. This makes it fairly simple to modify each .tt file so the POCO's and DbContext can be generated in different assemblies/namespaces.

Having your interfaces separate from the concrete objects makes things very flexible, and very cleanly separated. I can know define multiple sets of concretes using just the interface assembly references, without having to drag along (and expose) the concrete objects in some other assembly.

This separation of the entity interfaces would be extremely useful, I believe.
Coordinator
Jan 28, 2014 at 9:40 AM
It would be nice to be able to do that. I think the problem I had was that the .tt file scans the source files in the same project to find the entity interfaces, I guess it may be possible to scan files in other projects in the same solution, but then that may not always be what is wanted either. I'll have to think of a better way to control what gets scanned for entities - either when you add the .tt file to the solution, or when you run the .tt file (though the latter would probably get annoying).

If anyone has ideas or could point me at projects that do this stuff well, that would be most welcome!
Feb 13, 2014 at 11:09 PM
MS's Entity Framework actually seems to have two .tt files. One generates the entities, and one generates the context using the entities generated by the first.
The .tt file that generates the entities has a file reference variable that points back to the .edmx file used to generate both the dbcontext and the entities.
Since it is a variable, it is easy to move the entity generating .tt file to a different assembly (project), and then change the reference to the location of the .edmx file.

I believe a similar approach in BrightstarDB would probably serve all these needs.