Hi Everyone,
I have a question regarding configuration settings. In our previous
applications we designed an object (context) that held all the information
regarding security settings and database settings that was initialised when the
application was loaded and passed/set on each business object, this was
designed in VB6.
Having now moved over to VB.net and CSLA i was wondering how people where
working with configuration settings and passing the connection string around to
different business object that access the database.
How does this affect the business object when enterprise services/remoting?? primarily
at the moment we will be running our business object with ASP.net.
I would be very interested in know how this can be achieved simply and
generically.
Thanks, Tim.
Generally it is considered good practice to put your connection string only in 1 place in the .config file. So for a WebForms application this will be the web.config file and for a WinForms application this will be the app.config file.
It is not usually "passed around" to different BOs. But a standard method of accessing the data (i.e. an API or method call) is usually provided to get it in a standard way.
CSLA uses this technique. So for example, you might have two connections strings defined in your .config file - for example "Customer" for your Customer data and "Invoice" for your invoice data.
Each BO then identifies which database it should get its data from by name - either "Customer" or "Invoice".
See the ProjectTracker code for an example of this.
Tim FOrd:
I have a question regarding configuration settings. In our previous applications we designed an object (context) that held all the information regarding security settings and database settings that was initialised when the application was loaded and passed/set on each business object, this was designed in VB6.
Having now moved over to VB.net and CSLA i was wondering how people where working with configuration settings and passing the connection string around to different business object that access the database.
There's a property on the Application Context to get the connection string. I don't use it though, as I have my own DAL which worries about connections. The only exception is that my DAL provides a way for my business layer to open a connection and keep it open until the business layer closes, so that I can keep all data operations which should be in a transaction on a single connection.
With remoting, you'll need to keep that database in your Web.config for the web application which is hosting the data portal. There'll be no need for your client application to know the connection string at all, since all calls to the database are made via the DataPortal. The dataportal ensures that your BO is remoted to the application server before running data access code. You said that your UI layer will be built in Asp.Net. The web config for THAT site does not need to have the connectin string settings; only the remoting host IIS application needs the setting.How does this affect the business object when enterprise services/remoting?? primarily at the moment we will be running our business object with ASP.net.
Copyright (c) Marimer LLC