Paul,

Thanks for your comments, that is exactly what I am looking for.

My comment about the security was: It is a component of the abstract factory. If you don't like it, replace it.

Anyone else?

TIA

Rex

>PMFJI - just my thoughts
>
>>
>>There are a few negatives that immediately stick out for me:
>>
>>1. Everything is a DataSet, hence incurring the performance penalty of datasets.
>>
>
>In cases where performance is a major issue (ie. the dataset becomes a bottleneck), you can always switch to something like a datareader. After playing with both, I don't think it's a big deal in most cases. But that's just my personal opinion.
>
>>2. Since they are DataSets, you inherently are dealing with collections, which isn’t ‘clean’ when single instances are what is required.
>>
>
>Not sure what this means. There isn't much to "handle" with the collection if you just have a single table.
>
>>3. Tying several processes together in a workflow of business entities and other tasks in a transaction does not seem to be supported. Transactions seem to be initiated at the MM object level and don’t “fit” into a transactional workflow. Using Enterprise Services may get around this.
>
>Doesn't the TransactionBegin()/Clear/Commit/Rollback do what he wants?
>
>>4. MM based objects lose their context when used with webservices. Objects serialized and sent across applications no longer function due to running in a different AppDomain with different configuration files, and on a different machine that may not be able to talk to the backend data store.
>>
>
>Sure - that should be the case with any stateless environment.
>
>>5. There is no “sense” of n-tier design. You code against an object with CRUD methods. It internally may have a data layer, but that’s hidden. Business rules/processes/workflows are built into the objects themselves (since the transaction root is the object). You ‘typically’ wouldn’t have a business and data tier in this case; you just call methods on objects from the presentation tier.
>>
>
>I'm not even sure where to start with this one. The major comment is, how would he/she expect this to work.
>
>>6. To get a lot of the benefits of using this, you have to use their UI components and base pages.
>
>Sure. Why wouldn't you want to? That's the point of the framework.
>
>>7. The built in security is purely role based, and doesn’t fit into the roles/rights paradigm used by many applications at ODH.
>>
>
>I have no idea how they work at ODH, so it's hard to compare.