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
Inherits Csla.DataPortalClient.WcfProxy
Public Sub New()
MyBase.New()
MyBase.EndPoint = Settings.GetCurrentWcfEndPoint()
End Sub
End Class
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.
Imports Csla.DataPortalClient
Imports Csla.Server
Public Class G2Proxy
Implements Csla.DataPortalClient.IDataPortalProxy
Private _proxy As IDataPortalProxy
Protected Property Proxy() As IDataPortalProxy
Get
Return _proxy
End Get
Set(ByVal value As IDataPortalProxy)
_proxy = value
End Set
End Property
Public ReadOnly Property IsServerRemote() As Boolean Implements Csla.DataPortalClient.IDataPortalProxy.IsServerRemote
Get
Return _proxy.IsServerRemote
End Get
End Property
''' <summary>
''' 'Constructor to Initialize the Proxy to use remoting or not based off of the config file settings
''' </summary>
''' <remarks></remarks>
Sub New()
If Settings.UseRemoting Then
Proxy = New G2WcfProxy()
Else
Proxy = New Csla.DataPortalClient.LocalProxy()
End If
End Sub
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)
End Function
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)
End Function
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)
End Function
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)
End Function
End Class
A total of a whopping 59 lines of code were needed. Heck Yah!
Thanks Rocky.
dlabar:
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