One of the big dilemmas I came across before making Gemli a publicly accessible resource (open source project) was what to call the objects being loaded and saved. I’d heard “entities” and I’d heard “data models”, and I didn’t know the difference.

Truth be told, I’m still not entirely sure I know the difference. But after Wikipedia searches and other small research I came to the conclusion that:

• An “Entity” is a business object that is closer to being a domain object.
• A “Data Model” is more of a description of something as it relates to data; it is closer to a database record, including its schema.

This distinction was important to me because Gemli is built to support POCO with minimal code, but it also needs to work with the data at a database integration level, so I needed to know what to call the two kinds of objects (the POCO object and the object that actually represents what will be loaded to/from the database). Initially, I called the objects that represented the database record “DataEntity”, and then its property that spit back out the POCO object was called the “InstanceObject” or something like that. Really weird. Bleaah.

Anyway, now any POCO object that is suitable for being wrapped and serialized to the database is called in Gemli an “Entity”. Once wrapped into database-translatable semantics, it is called a “Data Model”.

This is why some generic interfaces in Gemli take a TEntity and some take a TModel. They are not named differently because they are inconsistent, they are named differently because a different kind of type is expected. If you pass in a TEntity, you’re probably dealing with a generic interface that will spit that TEntity back out in its original form. If you pass in a TModel, you’re probably dealing with a query object or a data provider that can only work with data models using Gemli’s data modeling semantics.

var Bob = new Person("Bob Smith"); // Bob is an Entity. Person is any ol' POCO class.
var BobRecord = new DataModel<Person>(Bob); // BobRecord is a data model.
BobRecord.Save(); // Bob is a new customer/employee/thingamajig.

var SueRecord = DataModel<Person>.NewQuery()
    .WhereProperty["FirstName"].IsEqualTo("Sue")
    .SelectFirst(); // Sue has a record in the database because she is an
                    // existing employee (and yes lambdas will come to 
                    // Gemli, sheesh!)
Person Sue = SueRecord.Entity; // Sue is a person, too!!

Not sure if this discussion is valuable to anyone, but that’s Gemli’s story on the word choices.