Re: Factories and lazy objects

From: James D Carroll (jamesdcarroll_at_hotmail.com)
Date: 06/25/04 

Date: Thu, 24 Jun 2004 23:06:48 -0400

Responding to Lahman:

> One should tailor the interface to persistence to suit the solution's
> needs, not the DB data structures. For complex applications that may
> mean the mapping of objects and tables or attributes and fields may not
> be an exact fit. If so, one needs to encapsulate the conversion rules
> so that the DB view can change without affecting the solution. OTOH, if
> the mapping happens to be 1:1 and things aren't very complicated, a
> simple class will do.

The underlying mainframe data IS quite complex and for that reason the GTM
team will work with the app developer (me in this case) to develop custom
"views". These are the strings that are returned and tend to be built
specifically for each app. There are literally hundreds of these. So I will
have _some_ leeway in terms of what data is returned and how its formatted,
but it _will_ be "negotiated".

> Note that for this semantics your MFC is acting as a Facade to
> persistence at the application level. IOW, MFC is doing for your
> application what GTM is doing for all applications.

Absolutely true.

> To avoid that dependency you might want to think along the lines of:
>
> * get info from 1
> [Client] ------------------- [MFC]
> R1 A
> | R2
> +------------+-------------+
> | | |
> [Production] [MainTest] [LocalTest]
>
> The R1 relationship can be instantiated to the proper subclass instance
> by someone else who understands the context of the access. Then the
> Client needs to know nothing about that context; it just does its thing
> with Account information. It will also simplify MFC by isolating each
> mode if there are significant differences in accessing Access vs GTM.

Again absolutely true and the reason that I posited my original as a
question about "Factory" objects. There would be no difference in parsing
the GTM string between MainTest and Production. The GTM is designed
expressly to return the same string (or View) whether the app asks for
either MainTest or Production for precisely the reason of allowing the
developer to write everything based on test, then "flip a switch" to hit
Production. Accessing LocalTest would be very different. Unless of course I
put a Facade in front of it..... hmmmm...... : )

> Note that Dispatcher has to have a relationship to the right Proc table
> in order to insert the region parameter in the massage. Somebody has to
> define that relationship and they will understand the context. So they
> would be the logical one to instantiates R1 or set a mode attribute in
> MFC. That keep Dispatcher out of the loop.

Dispatchor, in fact, would be the only one to have access to the Proc table
and would pass the region to the MFC as a parameter of MFC.getAccount(int
region). I had breifly considered giving the MFC access to the Proc table,
but I saw that as creating another dependancy that could grow ugly.

> This opens another Pandora's Box. What's efficient for the application
> may not be efficient for the DB. Another reason for making MFC a
> subsystem is that one can deal with DB optimization there. While hardly
> infallible, it is usually a good rule of thumb to minimize DB
> transactions, especially if the join is "compiled" in the DB. The MFC
> subsystem can then pull the entire Account "object" as a single dataset
> that it buffers in a local cache. It can then parse that dataset on an
> as-needed basis to resolve more limited solution requests. One can even
> add exotic LRU algorithms to the subsystem to deal with the local
> dataset cache when transactions are random and separated in time.
>
> Obviously this depends a lot on the nature of the transactions accessing
> Account-related information (e.g., a tendency for multiple transactions
> against different Account information clumped together in time). But
> there can be substantial performance benefits if one separates the DB
> access problem from the customer problem.

I think go whole hog with caching and the like would be overkill for this
system. I'm (the Dispatchor) only pulling the data out long enough to pass
it to the Process and then putting it back. And there's a very real 80/20
rule: 80 percent of the Processes only need 20 percent of all the Account
date that COULD be pulled. It those few that need something more that are
the bugger. And I really want to keep all the View String parsing localized
to the MFC. I think I might have the Dispatcher pass the DataAccess
component to the Account and do something like this:

interface DataAccessComp{
    public void getBasicInfo(Account a); // these would relate to the views
that we agree to
    public void getTransList(Account a);
}

class ProductionData implements DataAccessComp{...}
class ProductionTestData implements DataAccessComp{...}
class LocalTestData implements DataAccessComp{...}

class MainFrameConn{
   static DataAccessComp getDataAccess(int region){
        switch region{
            case 1:
                return new ProductionData();
                break;
            case 2:
                return new ProductionTestData();
                break;
            case 3:
                return new LocalTestData();
                break;
        }
}

class Dispatcher{
    DataAccesComp da = MFC.getDA(1);
    Account a = new Account();
    a.setDA(da)
    ... (Process, and Logging code to follow)
}

class Account{
    private DataAccessComp da;
    private String Name;
    private List Transactions:

    public setDA(DateAccessComp rhs){
            this.da = rhs;
    }
    public String getName(){
        if (Name == null) {
            da.setBasicInfo(this);
        }
        return Name;
    }
    ... same for Transactions
}

Take care and thanks again! 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.708 / Virus Database: 464 - Release Date: 6/20/2004

Relevant Pages

  • Re: _bstr_t conversion
    ... If I am building an MFC app, ... If I am building an MFC app or DLL with some ADO objects & calls thrown ... _bstr_t is also a very limited string type. ...
    (microsoft.public.data.ado)
  • Re: Creating and setting registry key value
    ... I have now discovered the mfc is not nearly so user friendly as the JDK. ... > There are significant poor style usages in the code below. ... But if you need a variable, CString is a better ... string to a CString? ...
    (microsoft.public.vc.mfc)
  • Re: Crash when reading a CString out of a CArchive
    ... Looks to me like MFC is doing exactly what it should do. ... You create an archived CString ... whose length is EEEEFFFF by faking the data, ... Why do you think 0xFF forces MFC to read WORD string ...
    (microsoft.public.vc.mfc)
  • Re: Crash when reading a CString out of a CArchive
    ... Reading invalid data is not the usual case, ... MFC to detect that error? ... MFC reads and _interprets_ data during string serialization, ... Why does MFC blindly trust that data in this ...
    (microsoft.public.vc.mfc)
  • Re: Count function
    ... this will tell you how many times the each string will appear in a cell in column A ... if the string can be a part of a longer string, the answer is more complex, do you need this? ... Account Data ... Account information ...
    (microsoft.public.excel.worksheet.functions)