Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
SIMPLE way to migrate to n-tier w/out long learning curve?
Message
From
25/04/2002 15:51:42
 
 
To
All
General information
Forum:
Visual FoxPro
Category:
Classes - VCX
Title:
SIMPLE way to migrate to n-tier w/out long learning curve?
Miscellaneous
Thread ID:
00649294
Message ID:
00649294
Views:
50
I am in the process of evaluating the various commercial frameworks and trying to figure out a way to integrate one of them (have looked at Codemine and MM so far) into my EXISTING applications, and to utilize them for NEW development.


But more importantly, I am trying to determine if it would be feasible to utilize the most important design principles of the frameworks, in my existing work, especially with respect to the concept of defining separate tiers for UI, application and data, without completely abandoning my existing code, with the intention of EVENTUALLY (over the course of the next 3 to 6 months) making FULL use of one of the frameworks.

Please bear with me as I am new at most of these concepts, and may be 'missing the boat in some (or all!) areas.

My SHORT TERM, not so ambitious goal, is to start, today, with using techniques that will lend themselves to 'minimizing the pain' of migrating code to n-tier, or a particular framework, WHEN I am ready. At the current time I simply don't feel that I have an adequate understanding of OOP, Business objects, rules classes, etc, to dive in and start trying to use one of the frameworks.

I have looked at both MM and Codemine with the intention of determining whether I could just start out with a 'small piece', either by making use of the concepts, or by using the classes, and not utilize the rest, for now. The most important piece to me, it seems, is the construction of a data environment that is separate from the form. Could one use the data environment/management classes of MM or Codemine only, without all the other stuff? For now, I don't feel I have time to dive into/learn about object oriented menu managers, forms collection managers, error handlers, etc. I also don't have complex needs in the area of toolbars, and managing complex interactions between forms. At the current time, most of my development is with Accountmate, and accounting package that has a fairly simple set of class libraries, a simple form class and set of control classes, and lookup container/controls, and a 'sort of' toolbar class that implements a set of save/cancel,ec. buttons inside a container.

Here is another newbie question: Why do I need a separate business object for each table or cursor, as appears to be the preferred way of doing things with MM (I'm not sure about Codemine)? Why can't the data environment itself, at the 'macro' level be considered a single business object that can be manipulated? Or why isn't a cursor object itself considered to be a business object. Why can't I just have one object that has add, edit, delete and find methods, and a property for what cursor it operates on? Why can't I also just have another object, that I would call a 'transaction object', that operates on the form/transaction as a whole, with savetransaction, deletetransaction and canceltransaction methods?

Again, another area that I am hazy on: If I understand the theory correctly, one OOP idea is that the business object is a separate layer from the data, and as such doesn't know anything about the 'type' of data that it will ultimately map to, and that there will be some translation layer (which I don't really understand) that will load base table data in and out of the business objects. But again, it seems to me that the cursor itself in a data environment should be the business object?? It seems that the cursor should be based upon a view, or even a manually created cursor, and then the cursor object will be abstracted from the ultimate data source, whether it is local vfp data, sql server data, etc??


And here is another newbie question: I think I understand that the idea of separating the data environment from the form is so that a separate object, or set of objects can be created as a com server. But why can't I just mark my form class as OLE Public, instantiate my form as com server, and call methods of the form. If I understand correctly, I can't do anything in a VFP COM Server that outputs to the UI, but, I'm guessing that I can just keep my form invisible. The OLE Public checkbox is 'there for the checking' when creating a form class. What would be wrong with doing this?

For starters I would be satisfied with a simplified approach and set of guidelines for 'not mixing' interface code with data manipulation code

I have read many threads on here about people's experience with frameworks. From what I have seen so far, MM and VFE are highly regarded, and are descendants of codebook. Codemine is also highly regarded, and from what I've seen and read so far, looks like it will be considerably easier to utlize, at least initially. With respect to whether the greater learning curves for MM or VFE are worth it, or provide benefits that are not found in Codemine, is not something that I can speak to right now, as I simply don't understand the concepts well enough, yet.

Any and all suggestions would be appreciated at this point.
Next
Reply
Map
View

Click here to load this message in the networking platform