2

I really like the concept of keeping a pristine domain model where you don't need to reference any 3rd party DLLs. I'd like to be able to design a domain model where you could use a fluent API from entity framework or mongodb to define your mappings outside of the domain assembly. I'd also like to be able to use Guids for Entity Framework and ObjectIds for MongoDB when it comes to entity IDs.

The problem is this, none of these four datatypes are ideal:

public Guid Id { get; set; }  // can't use ObjectIds for mongo
public ObjectId Id { get; set; } // not compatible with entity framework
public object { get; set; } // not compatible with entity framework
public string { get; set; } // EF has problems wiring this up to a Guid column

Does anyone know a clean way of defining some pristine POCOs that can use Guids in EF and ObjectIds in MongoDB? I'd like to be able to swap between the two persistence technologies without having to make changes to my domain model.

If I can have something generic in my POCO and define the data type in each FluentAPI that would be perfect but that has also proved challenging.

Landon Poch
  • 832
  • 1
  • 8
  • 19
  • Let me see if I understood (I know nothing about Mongo!). EF Code First recognizes properties with the prefix/suffix `Id`. For example, in a `Person` class you can set both `public Guid PersonId { get; set; }` or `public int PersonId { get; set; }` and EF will automatically set one this property as PK. Unfortunately, since I know nothing about Mongo, I don't know how that will work. – trinaldi Dec 21 '13 at 10:49
  • Just use a `Guid` for both? Documents in Mongo aren't required to use `ObjectId`s. I often just use a `string` for the `Id`. – WiredPrairie Dec 21 '13 at 13:32
  • 1
    @WiredPrairie I'd prefer not to use Guids because it looks like there might be some issues: http://stackoverflow.com/questions/11355792/with-mongodb-and-guids-for-the-id-of-documents-what-is-efficient-way-to-store-th Also, if I use a string then EF still has problems using Guids. I've also heard the aggregation framework doesn't work right if you store Guids as strings in Mongodb. – Landon Poch Dec 21 '13 at 19:41
  • I'm not sure that the Entity framework is a good fit for MongoDb. In fact, I'd say it wasn't at all. mongoDb doesn't care what you use for Ids. So, I don't understand your comment about the aggregation framework not working right without specifics. – WiredPrairie Dec 21 '13 at 22:21
  • @WiredPrairie, I'm not trying to use both together. I'm just experimenting to see if I can create a domain model where I could switch between the two without having to modify my entities. Maybe Fluent NHibernate is a better option for a SQL ORM. – Landon Poch Dec 21 '13 at 22:40
  • My point is that something that fits an Entity Framework model (or equivalent), isn't likely to be a good fit for MongoDB. – WiredPrairie Dec 21 '13 at 23:02
  • @WiredPrairie, I'm sure some things would be fine with both. I just want to know the best way to design the entities so they are compatible with both. – Landon Poch Dec 21 '13 at 23:06
  • OK. It's not really often the case that they should be compatible. A relational model doesn't fit well into MongoDb as there are no joins in MongoDB, so relationships, etc., need to be handled differently to be efficient. I'd guess you'll need the Class Map support from the MongoDB C# driver: http://docs.mongodb.org/ecosystem/tutorial/serialize-documents-with-the-csharp-driver/#creating-a-class-map. – WiredPrairie Dec 21 '13 at 23:10
  • I've used the FluentApi class map stuff for Mongo and it works great. The problem is the EF (and NHibernate now) Fluent API isn't robust enough to handle an object datatype primary key like mongo is. – Landon Poch Dec 21 '13 at 23:22
  • I am curious if there's a development in this department? – dereli Aug 22 '18 at 17:12
  • I just had the same problem and I ended up using GUIDs for both, MongoDB and Postgres. – amedina Nov 24 '19 at 14:01

0 Answers0