Rex, perhaps they need to hire a new consultant? :)

If MM.NET is not n-tier to this consultant then I don't know what is. To me there is indeed a strong sense of n-tier-ness to MM.NET. We're using MM.NET at Delta Air Lines if you want to drop a name to your client.

Hope all goes well for you.

Regards,
Carl.


>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.