My application touches multiple databases on multiple servers, that will be in different levels of development (some with newer columns, some without). I'm planning on having a seperate dataportal for each environment running on different machines. The Application itself, should be able to access different environments without the user having to touch the app.Config file. This presents a problem because it is assumed that you would have a single dataportal in the app.Config file and this is what CSLA uses to know where to communicate.
What changes will I have to make, so that CSLA will support going to a different server when making a DataPortal call depending on what environment the user has selected?
Would it be easier to progamatically update the App.Config file when they select a different environmnet, or would it be easier to edit the CSLA framework so it checks to see what environment is selected before determining what dataportal settings to use?
Search the forum for phrases like "custom data portal proxy" or "custom data portal channel".
The simplest and most direct solution is to create a custom data portal proxy that gets your server URL using whatever technique you choose, and then uses that URL to contact the server.
The WcfProxy can be subclassed to do this one way, because your subclass can set the EndPoint property to control the name of the endpoint used from the config file.
Alternately, you can simply copy the CSLA proxy into your project, change the namespace, modify the proxy to use your new config scheme and then tell the data portal to use your proxy instead of the standard one. Since the data portal is all interface-based this is pretty easy to do. Just read through Chapter 4 to see how the proxies work and are created and you should be able to make your own.
This was a lot easier than I thought it would be.
There were two things I wanted to be able to accomplish.
1. Connect to multiple WCF endpoints
2. Be able to control whether I was going to be doing it locally, or remotely by setting a true/false value in the config, not by which proxy I was using which means one proxy class was going to have to handle both.
The solution to #1 was to Inherit Csla.DataPortalClient.WcfProxy. The code need for this is shown below
Public Class G2WcfProxy
Public Sub New()
MyBase.EndPoint = Settings.GetCurrentWcfEndPoint()
The solution to #2 was to create my own Proxy that implements the IDataPortalProxy class, and contains a pointer to another IDataPortalProxy that would be either the LocalProxy, or my own proxy.
Public Class G2Proxy
Private _proxy As IDataPortalProxy
Protected Property Proxy() As IDataPortalProxy
Set(ByVal value As IDataPortalProxy)
_proxy = value
Public ReadOnly Property IsServerRemote() As Boolean Implements Csla.DataPortalClient.IDataPortalProxy.IsServerRemote
''' 'Constructor to Initialize the Proxy to use remoting or not based off of the config file settings
If Settings.UseRemoting Then
Proxy = New G2WcfProxy()
Proxy = New Csla.DataPortalClient.LocalProxy()
Public Function Create(ByVal objectType As System.Type, ByVal criteria As Object, ByVal context As Csla.Server.DataPortalContext) As Csla.Server.DataPortalResult Implements Csla.Server.IDataPortalServer.Create
Return _proxy.Create(objectType, criteria, context)
Public Function Delete(ByVal criteria As Object, ByVal context As Csla.Server.DataPortalContext) As Csla.Server.DataPortalResult Implements Csla.Server.IDataPortalServer.Delete
Return _proxy.Delete(criteria, context)
Public Function Fetch(ByVal objectType As System.Type, ByVal criteria As Object, ByVal context As Csla.Server.DataPortalContext) As Csla.Server.DataPortalResult Implements Csla.Server.IDataPortalServer.Fetch
Return _proxy.Fetch(objectType, criteria, context)
Public Function Update(ByVal obj As Object, ByVal context As Csla.Server.DataPortalContext) As Csla.Server.DataPortalResult Implements Csla.Server.IDataPortalServer.Update
Return _proxy.Update(obj, context)
A total of a whopping 59 lines of code were needed. Heck Yah!
My application touches multiple databases on multiple servers, that will be in different levels of development (some with newer columns, some without). I'm planning on having a seperate dataportal for each environment running on different machines. ...
It is possible to support multiple databases from a single data portal without making any changes -- our application supports 3 different databases using just one portal.
Essentially what we did is that each business object is associated with a named schema, and the connection strings for the schema are retrieved from the config file by a layer that sits between the BO and CSLA.
With a 2-tier deployment, the local data portal just reads the database directly. With a 3-tier configuration, the client connects to a single application server. The application server has it's own configuration which retrieves the object from the appropriate back-end.
If you need multiple application servers, then you have to do some of your own custom legwork, but it's possible to support multiple databases out of the box
Copyright (c) Marimer LLC