>>Separating the business logic from the interface and data source is what business objects are all about. A true business object should exist as an entity unto itself, independant of the data source or application front-end. Codebook business objects approach this philosophy, but could not be implemented because they could not be compiled into multithreaded COM components. Therefore, the business objects remained application dependant.
>
>Well let me open up the can of worms I've been stewing on since I did Kevin's training in April. (Sorry Kev, hopefully you'll jump in here & set the record straight) And before I go here, let me repeat that I am still a big fan of MMF and this is just my opinion of where the framework stands today in regards to going N-tier.
>
>The Mere Mortals business object is currently tied to a data environment, and the VFP data environments means local/remote views or tables. And since the UI classes are all setup to expect to work with or bind to views/tables, the current state of the framework doesn't easily adhere to a true physical N-tier implementation in my very humble opinion.
>
>By true N-tier I mean developing an app with the presentation layer or UI that binds to the middle tier business object. Right now, a presentation layer developed with MMF is setup to bind to the data source managed by the BizObj. But it still is binding to a data source. Windows DNA tells me if I'm going to N-tier correctly, I need to bind my UI controls to BizOBj and nothing else.
>
>So if I want take advantage of SP3 fixes for VFP and roll my MMF-based business object with it's built in data environment (that is a container for tables/views) into a COM object... and lets say I want that COM object to reside in MTS, how in the heck can I have my UI still bind to that table (or view which acts just like a table) inside of that BizObj thats packaged for MTS, and yet keep everything else to working in accordance with the ready-made functionality of the framework? That just doesn't fit with what I've been learning about Windows DNA and N-tier. To do this right I need to bind my UI controls to my BizObj properties or methods, not my datasource attached to my BizObj.
>
>So the way I see it, I need to do extensive retooling of the framework classes (both BizObj & UI stuff) to get away from the data environment based BizObj and get it to work with ADO recordsets manipulated by my BizObj. Then I could bind my UI to the BizObj only, no data environment partner in the mix... and then my BizObj can become a nice clean COM component and go off into the MTS sunset if need be.
>
>Now this is in the current state (v4.2) of the framework. When I attended the training Kevin mentioned lots of forthcoming improvements in the N-tier arena. And we can see some of that in the works with changes made in v4.2. Like you've already mentioned in another context, MMF is a part of the Codebook history, and Codebook was way ahead of its time as far as Client/Server. What was first layed out in the Codebook book as a "3 layer approach", is now commonly seen as N-tier. But at the time of conception... all we knew was views and views were the latest s***. IF you look at the life span of another very popular Codebook-based framework (Sorry M.F., I wont actually say it in Kev's forum :) ), they did a major rewrite of their VFP6.0 version to take it from it's Codebook roots to the N-tier realm. So hopefully in the near future, Kevin's N-tier revisions will be available to us and then I would be able to agree with your statement that I asked you to explain.
>
>And since I'm on a roll here...
>In the current techno trend, the way I'm seeing it we the VFP community need to change our mindset on views and think in turns of ADO and turning recordsets into cursors. Which sort of leaves buffering hanging out in left field for the time being. But I would think VFP's buffering capabilities is what makes it a such a powerful contender for the M$ spiel of promoting VFP as the middle tier product. I would hope somebody can give me a different perspective here, because to my dismay I see this VFP mid tier deal without buffering implemented as a big fat catch 22.
>
>just my semi-inflated $.02 worth

I'd say I got my money's worth! But as far as I know, Kevin is coming out with a major rewrite of the framework. And who says you are forced to use ADO to be contender in the n-tier environment? ADO in of itself has major limitations, and if all the functionality is built into the bizobj, then perhaps the only thing to do would be to tie into the bizobj and not the view that the bizobj is based on. You made some excellent points, and I too wonder which direction will be taken in the next version. I'd love to hear from Kevin at this point...