Which ORMs Support which workflow styles

Question

I've worked with a few different ORMs in a few different languages -- There seems to be no agreement on what kind of thingy should be the source, and what should be generated.

Consider these thingies:

• Entity: A plain old object. It does stuff.
• Mapper: An object that creates an Entity from the DB, or persists it back.
• Table: A database table.
• Model: A separate model that describes an abstract thingy.
• Wiring: A description of how the parts of a Table and Entity are related.

That gives us these workflow styles:

• Model Driven: You write a Model, and the Entity, Mapper, and Table are generated.
• Entity Driven: You write a Class, and the Mapper and Table are generated.
• Table Driven: You make a Table, and the Entity and Mapper are generated.
• Wire-up: You write Class, Table, and Wiring, the Mapper is generated.

The Questions:

• Is there another style I've failed to notice?
• Which ORMs Support what styles?
• Is there a standard vocabulary for this? (I just made up the above.)

Answer 1

From what I have seen so far, using .NET, Entity Framework supports all of the above and NHibernate supports what you refer to as Model-Driven, Entity-Driven and Wire-up (without using additional 3rd party libraries).

NHibernate is a port of Java's Hibernate, so I assume they support the same flows.

Answer 2

I apologise if this might be a little off topic, but it's too big to fit as a comment, so advance warning, if others don't think it helps the topic I'll delete it.

A key question is if you and your application own and are the only client that accesess the database.

If you need to work around an existing database, then out of the block, generating the database from the Model is probably out of the question.

If created by your system or not, it will be accessed by other systems (which means you can't just randomly change the database to implement logic, or even more extreme, other fields/tables might be added to faciliate the 3rd party applications), then you need to think about what workflows will allow you to abstract the database details from your implementation to prevent you having to do major rewrites.

These requirements might change throughout the projects lifespan, as you might start off as the sole consumer and in the future other applications might access the same database directly. This might be where you have a "Entity Based" workflow as you call it, where you have a layer that represents the actual DB tables, and a Models that represents your data used in your system are abstracted from any changes to these.

And sometimes needs change, thus the ORM and workflow you use should be mindful and at least partially capable of surviving in a future that might be out of your hands. Imagine an enterprise (aka political) environment. One day a DBA turns up and says, "all data access is now through SPROCs". These type of situations push you towards the "Mapping" as you called it.