Vlad,
>As about encapsulation, I already made the point that data sessions look quite weird from the OOP point of view.
The Session class fits quite well into an OOP model. Maybe you are referring to data sessions in general in your statement above? I think of the private data session as the "walls" of the Session object. Inside those walls, anything goes -- without any concern for what's happening outside the walls.
>- ... Are you saying that business rules for a single COM server call are so complex that we require to divide them to different routines, each with its own data session just because they might conflict with each otehr? I never met such complexity of business rules.
I mentioned an example of a COM server method that instantiates and calls into one or more business object classes based on Session. This is done without any fear or complexity of conflict with anything else happening in that COM server method, and the same Session-based BO can also be used in multiple other ways with no changes to code. That's the importance of encapsulation.
>- Because all native PEMs of any VFP object could be hidden, the point that session object have less PEMs makes no sense - we can use custom object with the same success and size of the interface part transferred over network after hiding all useless PEMs.
Maybe Microsoft thought it was a good idea to provide a class that required no additional work to accomplish that -- I think you made the point earlier that it's best to have classes that save the developer additional work and coding.
>>Session is also very useful for encapsulating blocks of old-style procedural code (which perhaps may open tables in certain work areas) as a first step in fast migration of older projects.
>
>I can make the same with good success using our environment controlling class. It remembers all aliases opened in the areas and their properties, after routine call it restores environment to previous state - closes any extra opened aliases, restores order/filters/bufferig mode, warns developer if some alias closed in routine (that is usually restricted).
For those who don't already have an environment controlling class, the Session class handles it all with no additional coding. Switching to Session would greatly simplify that part of your framework and might provide extra speed as well.
>...By such way, from one side, you have a tool to close extra opened aliases, from the other side, you will see what is wrong in your routine and what is needed to fix in it to use in most places.
Again, the built-in encapsulation of the Session class will automatically close extra opened aliases and will simplify such problems as "fixing it to use in most places".
>...Note that there are situations when you need to use in routine already opened alias. With private data session this is possible, but you will require to switch between data sessions inside of routine taht is quite the mess.
That would not be the case in a business object designed for maximum flexibility, which can stand on its own with no outside dependencies. For cases where you must depend on an alias already opened, I would suggest reconsidering the design to pass the data into the routine via ADO or XML or a SCATTER NAME object, or pass in a data object reference. In many cases, all you need is to call methods in the business object with keys (from your open alias) passed in as parameters.
Otherwise, in those few cases, if the design cannot be encapsulated, just don't use Session. However, you're probably not talking about a generic reusable routine in that case, but something specialized to a particular method or form.
>I will appreciate your answers because it is always good thing to share experiense using such discussions.
These kind of discussions are great for thinking and re-thinking about design and application architecture. Thanks for giving your ideas.
