Calling one CSLA library from another app

mtagliaf posted on Tuesday, February 12, 2008

I've got 2 large, independent CSLA-Architecture apps. Both have their own business library.

Now (of course) the users are asking if some of the reports in App 1 could be accessible from App 2. The reports in App 1 use business classes from App 1, so I need to somehow link over to the App1 CLSA library and use those classes.

The main problem, as I see it, is the BusinessIdentity/Principal classes are different/custom in each application - I cannot set the user's CurrentPrincipal to 2 different classes. The reports use some "application-level" settings that I'm storing in the BusinessPrincipal class.

I defintely do not want to merge these applications or CSLA libraries, either. El-nightmare-o.

Are there any other options?

ajj3085 replied on Tuesday, February 12, 2008

I have similar concerns. My current thinking is to move reporting to Reporting Services and get BOs out of the mix. Currently, my reporting BOs aren't doing a whole load... just loading data which is then displayed. Seems rather pointless.

Alternately, you could move select classes to some base shared assembly. A common base class for both principals, and the reports would go together.

HTH
andy

mtagliaf replied on Tuesday, February 12, 2008

One thing - I never got on the ApplicationContext bandwagon. I have custom BusinesIdentity objects that have all my user-specific fields in them.

If I move these to the ApplicationContext, and make sure they're set from both CSLA apps, does this fix my problem?

david.wendelken replied on Tuesday, February 12, 2008

We use active directory, so that may influence things a bit.

We put our custom principle extensions into the csla library, so all our business object libraries share the same user identity object. After all, I don't change who I am when I use a telephone or a pad and paper!

rsbaker0 replied on Tuesday, February 12, 2008

mtagliaf:
...
The main problem, as I see it, is the BusinessIdentity/Principal classes are different/custom in each application - I cannot set the user's CurrentPrincipal to 2 different classes. The reports use some "application-level" settings that I'm storing in the BusinessPrincipal class.
...

One possible solution is to extract a common interface from both classes (the minimum needed to generate your reports). This can be defined in a separate assembly to avoid dependency issues. (or alternatively, one of your libraries could own the interface -- it depends on the specific implementation). The reports would be refactored to access only the interface, not the specific BusinessPrincipal objects.