Our application has a main WinForms UI, and an AutoCAD extension UI which is hosted by acad.exe. There is also a second, separate AutoCAD extension which uses some of the business objects, UI components and the csla.dll instance of the primary application.
We want to
We're using a local data portal. I've looked at chapter 15 which talks about the WcfProxy, and 21: WCF Service Interface. This is a pretty basic cross-component communication requirement, so any suggestions?
Thanks in advance.
Michael
In my view, cross-application communication should follow an SOA model. Which means you define message contracts and send messages back and forth between the applications.
That means no "sharing of objects" as such, though you can certainly pass object data back and forth through the messages - just not objects in the way the data portal does.
What if it's the same, trusted application, just a different UI, as the case is with our AutoCAD extension?
It is probably fine then, as long as you remember that CSLA isn't threadsafe. So both "parts" of the app need to be on the same thread, and realistically the same AppDomain.
Which technology/approach would you take to solve the problem of serving/caching the business objects to the two UIs?
Pat Helland gave a talk some years ago where he described four types of data:
Resource data is mutable - read/write data that is stored in your database.
Reference data is immutable - read-only data that is versioned, so if you edit it you create a new version and the old version is still there (like a newspaper - you can always get yesterday's paper, even years from now - and it is unchanged).
Request/Response data is transitory - it is read-only and exists for short periods of time while in transit.
Activity data is mutable, but isn't typically stored. Think of this like the fields of your objects in memory.
Of all these, the only type of data you can safely cache is Reference data. In all other cases you run the risk of stale data.
I suspect you want to cache Resource data (though technically if it is in memory it is Activity data - but still...) That's the hardest to cache, because it is the most likely to become stale in any multi-user scenario.
In any case, remember that CSLA objects are (typically) retrieved using a factory method. Most factory methods are one line of code: the data portal call. But there's nothing that says they can't be more complex, possibly managing a list of retrieved objects that are held in memory and returned out of that list rather than using the data portal.
If you want to be fancier, you could create your own client-side CachedProxy for the data portal. This proxy would cache objects (maybe based on some custom attribute you define) and return the objects from the cache, or invoke WcfProxy (or whatever) if the object isn't in the cache.
Either way you'll have to deal with stale data.
And either way you'll have to deal with potential memory leaks. Holding a business object in memory can be problematic if you also use data binding. When a window/form/page/usercontrol sets up a handler for PropertyChanged, that actually creates a reference from the object to the UI element. If the object never goes away, that event is probably never unhooked, so that reference probably never goes away, so the UI element is forever stuck in memory.
How you solve that is not something I've taken the time to figure out, but I suspect it isn't easy :(
You can use a distributed cache to acomplish this. Check out Windows Server AppFabric http://msdn.microsoft.com/en-us/windowsserver/ee695849.aspx
Copyright (c) Marimer LLC