New feature request to support multiple remote data portals.

Often in shops such as mine you're left in a situation where you're string together lots of already written assemblies to make a final product.  Case in point in my current project.

We have a security framework that uses CSLA at it's core. (A)
We have a library that is a mix of legacy DTO's (prior to us incorporating CSLA) and CSLA objects. (B)
We have a library that is pure CSLA for working with another core system in the company. (C).

We DON'T want applications that use (A) to ever use the assembly in 'local portal' mode - we insist that they use the remote data portal and point to a particular server where we keep the security database, hash type, etc - we don't want every Tom, ***, and Sally knowing what that assembly hits on the remote machine.  This information is living on a remote portal that most developers don't have access to gives people a sense of security.

Currently (C) is going to be upgraded because of performance reasons so that all applications that use (C) have to use remote data portal where the remote data portal has a lot closer access to the system it communicates with.  THIS IS NOT THE SAME LOCATION WHERE (A) IS.

(B) has been and always will use the local data portal because of reasons too long to get into.

So individually these requirements aren't a problem, until your application has to use assemblies A, B, and C.  Currently CSLA either has remote data portal at X location or it uses local data portal.

I'll will do this on my own if need be, but I think this feature would benifit the entire community, be a nice feature for CSLA overall, and you guys could implement it a lot quicker and BETTER than I could.

I would like to see a client configuration section for the client data portal.  This would be optional and by default the data portal would work using the appSettings as it always has (for backwards compatability).  If this configuration section is present on the client though, the appSettings are ignored.

The configuration section would basically map what assembly goes to what remote data portal, for example:

<csla.client>
    <dataportal>
         <assembly name="Assembly, Version=1.0.0.0, PublicKeyToken=null, Culture=neutral"
                  proxy="Csla.DataPortalClient.RemotingProxy, Csla"
                  url="http://somehost/RemotingHost/RemotingPortal.rem" />
         <assembly name="Assembly, Version=2.1.4.0, PublicKeyToken=null, Cuture=netural"
                  proxy="Csla.DataPortalClient.RemotingProxy, Csla"
                  url="http://someOtherHost/RemotingHost/RemotingPortal.rem" />
         <!-- this would be the default for any assembly not mentioned above, but can be declared explicitly also - useLocalPortal is optional attribute that if set to true ignores any enteries for the name, proxy, url attributes and default is false (obviously for the above to work) -->
        <assembly name="Assembly, Verision=1.0.0.0, PublicKeyToken=null, Cutlture=neutral"
                 useLocalPortal="true" />
    </dataportal>
</csla.client>

This also infers that one assembly communicating to remote location Y could also communicate with location Z through enterise services - they don't all have to be the same type of server portal proxy.

Thoughts?

I see. From the other thread (http://forums.lhotka.net/forums/thread/21918.aspx) I thought you were chaining data portals. But that is incorrect - you just want to have two data portals and to call different ones for different object types.

You can do this by creating your own data portal proxy class. This runs on the client and is invoked by the client-side data portal. This proxy is responsible for routing the call to the server, but you can create your own proxy that routes the call to various existing data portal proxies (like the local and WCF proxies or whatever).

Your proxy would need to have some metadata scheme by which it knows what objects to route where - similar to the config file concept you are describing.

I don't plan to do this in core CSLA, but this scenario is one of the primary reasons I allow you to transparently use your own proxy as I'm describing here.

I think I follow what you're saying; but this implies for each application I have to create this custom data portal proxy, whereas I'm thinking more of a global solution for all of our applications by putting the code down in the CSLA core itself.

But building upon what you said....and perhaps what you were getting at my my brain is just fried from a 70 hour week....

I should be able to create my own proxy in a seperate assembly, which then all application could use (giving me the re-use I desire) without having to modify the CSLA core.  So basically I would just instead of in the appSettings pointing to a remote proxy, I'd point to my custom proxy, which then would in-turn use the remote, local, or whatever proxy based upon my metadata?

I think that makes sense?... :)

Yes, put it in a seperate assembly and reuse it - that is exactly what I'm talking about doing.