In the past, an ObjectRelationalMapper was good enough if you were able to load objects from a database (or save them to a database), but now, developers need more, it needs not only to be object oriented and elegant. It needs to be easy... easy to bind those objects to a form of UI (a WinUI or a WebUI); we need to catch up with NeXT's (now Apple's) WebObjects (http://rentzsch.com/webobjects/introTo5).

ObjectRelationalFramework''''''s that do not integrate with a ModelViewController framework are still in the Stone Age (to know what I mean, read http://rentzsch.com/webobjects/introTo5).

The need for integration with ModelViewController is because we need to reduce the amount of code written (if you're writing code, then you're doing something wrong). As Rentzsch says: each line of code is an expensive responsibility. It has to be written, debugged, documented and maintained. Since WebObjects strives to minimize coding, it saves you much time and money. .NET (and Java) ORM need to fight for the same goal... object relational persistence without writing code; all you have to do is:
 * Draw your model
 * Drag and drop "object views" that allow visual databinding with the controls in the UI
 * Drag and drop an "ObjectPersistencyManager" to the form, bind it with the "load button", the "delete button" and the "save button" and...

Voilà! you can do CRUD (Create, Read Update, Delete) and you have not written a single line of code.. that is the final objective, to be able to do that, you need integration between the Model (the Object Relational Framework) the View (WinUI or WebUI) and the Controller(User Process Framework). Of course, that has no value, if you can not extend it using custom code, but that must be done only when custom business logic needs to be represented, (and in many software systems, lots of Views only do simple CRUD, but you need to write more that two hundred lines of Java or .NET code!) -- LuxSpes

Is the SeamFramework the answer to this requirement for the JavaPersistenceApi ObjectRelationalMapping world? -- LuxSpes

----
''Why does the above text refer to the ModelViewController pattern in relation to the WebObjects page? The referenced article does not refer to that pattern, and I have a feeling MVC gets mixed up with MultiTierArchitecture. Opinions?''

----
Perhaps reading FourLayerArchitecture can help clarifying the issue? IMO ModelViewController is about separating:
* PresentationLogic(View)
* ControlLogic (Control),
* ModelLogic (Model)...
and MultiTierArchitecture is about separating
* PresentationLogic (UserInterface)
* ControlLogic (BusinessFacade, BusinessRules)
* DataAccessLogic (DataAccess, Model)

So it seems to me that multi-tier architecture derives/is related to ModelViewController... -- LuxSpes