Hi All,
I just need to be clarified on something with Csla.net. Any help will greatly be appreciated.
Does it make sense to have multiple data portals in Csla? I mean to say I have different kinds of data portal defined. Depending of type of data operation I need my request will be redirected to appropriate data portal.
A use case for this could be e.g.
I had a set of 5 applications, each one designed using Csla.net. They are almost independent to each other but share only authentications and authorizations part from a common DB. Now each of perform different kind of functionality but all 5 can be used from a single UI. And I need to host all of them on different server.
- Ramesh
Thanx for the reply. But I am talking a bit different.
I just want to dedicate servers to performs operations specific to data portal. Which can also help me in load balancing of seevrs. Each is dedicated to perform specific operation based on which we can give access to others.
This could be an interesting challenge - for an Einstein!! Me, I think I'm a mort ...
I have a need to be able to support multiple data access servers, brought about by one specific thing; SQL 2005 and its new Integration Services. I can see that the licensing differences between DTS (where all our LAN PCs had the DTS runtime locally) and SSIS (where they can't for cost reasons) means that we need to be a bit clever with ad-hoc execution of packages that we do from LAN apps. We will end up with a SQL Server that is configured to run packages but need to execute our custom code to run the package on the server rather than on the client as we are currently able. This is what CSLA.NET is great at - write a custom data access object and let the framework worry about where to run the data access code to get it to work, so CSLA.NET feels like the way to get around the 'challenge' we now face.
I can see that for a deployment that uses an application server, you simply need to ensure that the app server has a SQL Server license and can therefore run DTS packages. This costs money but is perfectly doable. However, what about when no app server is used for the deployment? Then, I need to force my command objects that will perform SSIS package execution to run on a SQL Server despite all other data access code running locally.
It is of course possible to mark all objects other than the SSIS command objects with the RunLocal attribute and then configure CSLA.NET to use a suitable channel adapter, but this removes the flexibility of switching to a three-tier physical deployment in the future and therefore fails to achieve the benefits that CSLA.NET solutions strive to maintain.
Therefore, I can see that I need to be able to furnish some objects with an attribute that tell it to use a specific data access configuration whilst allowing all other objects to use the default data access configuration. Whilst I'm at it, it feels like the right thing to do to expand the framework to support multiple specific data access channels plus a default, then every base will be covered now and in the future.
So, I can feel a need for adding a config section for a modded framework to consume that supports multiple named (or numbered?) data access configs. I've not worked out how to do this, but I'm sure I can have a go. The only thing I can feel being a pain is that the attribute can't use an enum to choose the necessary channel (thus making it 'type safe'), unless it is possible to add design-time support for loading an enum from a .config file. Is this possible? This is a bit like what is done for resources, when a strongly typed object is available at design time despite the resources being configured in XML (My.Resources.CreateNotSupportedException, for example) but I suspect this is done through UI trickery rather than generally available functionality. Am I wrong?
Need - enter multiple named configuration settings in a .config file and use those names in code from an intellisense drop-down to select the required channel for each object that cannot use the default.
All input greatly received!
Andrew
Copyright (c) Marimer LLC