I'm trying to build an application that interfaces with another vendor's software. I would like to be able to discuss it without using names because the topic would seem to be important for other situations, too. But I'll name the name: Microsoft Small Business Accounting (SBA).
The SDK seems very well thought-out and constructed. It offers an object model and insists you use it rather than access the underlying SQL Server data directly. It even offers that object funtionality via defined Interfaces to insulate you from version change issues (although you can use the actual instance methods if you prefer).
I was confident that I could build "side-by-side" BO classes with SBA "pieces." I figured my BO would have properties needed by myApp only. And it would have properties that SBA handled, as well. All I would have to do for the crud operations is code the work to manage myApp-specific properties as usual and add calls in my DataPortal_XXX methods to those SBA API methods and things compiled fine.
The Fetch stuff in my proof-of-concept app worked so well that I rolled up my sleeves and dove in. But when I began to deal with editable objects, I got the miserable surprise when I BeginEdit that the calls to the SBA API have made my BO non-serializable!
Can I wrap their API somehow and get around this or is this an architectural incompatability that I can't economically hurdle?
Thanks is advance,
>> Do you have class level variables that are SBA objects? If so, you can mark them with the <NonSerialized> atrribute so they don't get serialized when BeginEdit is called. <<
I had been hoping to have a single BO whose properties persist in DP_XXX mthods with calls to MY DB for some of the properties and calls to the SBA API for others. Scratch that!!
From your question, I now envision a "shadow SBA object" that would be a child of my version of the BO. In the DP_XXX methods of "my" BO I would call the child's own CRUD code rather than run it in my BO, right?
I'm only trying to think of this now for the first time, but I'm expecting that the child (and therefore its properties) won't be able to take part in the Undo operations, right? So it will probably be most efficient to just implement all the properties I need in MY BO (some being duplicates of the ones in the child) and handle the getting/putting of the values between parent and child just after Fetch and just before Update operations. So, for example, the factory GetMyBO() method would call the shadow object's fetching method and then call the DataPortal.Fetch so that my own DP_Fetch code is executed. In my DP_Fetch I would populate my "non-SBA" properties from my DB and the others with their corresponding property values from the shadow/child object. Similar treatment in the Save() implementation.
The UI developer won't even be aware that there are two data stores for the object and needn't care.
Does it sound like I'm on the right track, or would you like to offer a course correction?
Thanks!
Copyright (c) Marimer LLC