Mts Persistence

To avoid repetition please have a look through DnaVsOo, ContainerManagedPersistence, ComponentManagedPersistence, and InheritanceManagedPersistence before commenting here (if you haven't done so already).

I'm going to start a discussion with a question. In a Microsoft DNA application we would have: i) Browser - IIS/ASP: User interface ii) Application Server - MTS iii) Data Server - ADO/SQL Server

Currently Microsoft's official approach to persistence is data modelling driven using ADO/SQL.

Are there any Object-Relational mapping layers out there that can meet (near enough) the same performance and flexibility as ADO? And offer close integration with ASP/VB?

Or how would you tackle persistence in an MTS environment? -- PeterForeman

Currently Microsoft's official approach to persistence is data modelling driven using ADO/SQL. The problems with this approach are as follows:

* ?

For example: It violates "do something once and do it well". (There is a subject for this but I can't find the title.) In the Microsoft examples the code is repetative.

You can't easily see the business logic. Often the business logic is hidden in the midst of COM code (yuk!) and SQL code (yuk!).

OO is good for real world analysis - but maps to this kind of implementation relatively poorly.

I can't help thinking that there is a better way. Any suggestions?

-- PeterForeman

EnterpriseJavaBeans?

You can't easily see the business logic. Often the business logic is hidden in the midst of COM code (yuk!) and SQL code (yuk!).

Restated... As a business application programmer, the business logic is what I want to focus on, and I would prefer to have it in one place as much as possible. (And not be too cluttered with other low-level-detail technical logic.) Also, the business logic is what should make sense to the business users, and sometimes it should be surfaced in a power-user interface.

-- comments by BobHaugen, JeffGrigg and at least one other person.

To answer the point - yes as a user of a component you're right. However as a maintenance programmer going back to the component you'd be looking at a whole host of SQL and COM code (parsing record sets and getting interfaces). There is no layering of the design, it is straight into the nitty-gritty detail. Typically the actual business logic code may be a few lines (hidden) amongst a mass of glue-code. In an ideal system it would be good to hide the glue, exposing only the business logic coding. The golden rule of OO is that the system should model the real world, and the code should look like it is manipulating real world entities.

Here's a test - go to a bit of Microsoft C++/MTS example code and without looking at comments and the function name (get a friend to take them out) work out what it does. Go to a bit of OO code and do the same. The OO code will be much easier to understand.

It's not possible to entirely get away from glue but things can be made a lot better. I have a few ideas which I'm working on to improve the style and readability of MTS code, which will not sacrifice performance (too much). -- PeterForeman

Back to the original question:

> I'm going to start a discussion with a question. In a Microsoft DNA > application we would have: i) Browser - IIS/ASP: User interface ii) > Application Server - MTS iii) Data Server - ADO/SQL Server > > Currently Microsoft's official approach to persistence is data modelling > driven using ADO/SQL. > > Are there any Object-Relational mapping layers out there that can meet > (near > enough) the same performance and flexibility as ADO? And offer close > integration with ASP/VB?

I don't know of any, but that doesn't mean they don't exist. The object<->relational mapping issue is a hard one. The best place I know of to get information to solve this problem for your system is inside Tim Ewald's head. You can crawl in there by waiting for his book (a long time) or by going to his course (http://www.develop.com/dm/Course.asp?id=31).

> Or how would you tackle persistence in an MTS environment

Via some kind of hand-rolled object<->relational mapping. <sigh>

See ScottAmbler's comments on object/relational mapping:

http://www.ambysoft.com/mappingObjects.html