4

I've got a web service (ASMX) that connects to an oracle database and I think my architecture is not the right one.

To access the database I'm using a DLL that has all the database logic and returns completed objects. The oracle connection is created within the DLL, so the database server, user, and pass is hardcoded in the code what I know that cannot be ok. My question is about where to create the connection to the database, and how to configure the server/user/pass parameters in an external configuration file but not to be reading it each time I have to connect to the database.

Right now I have:

ASMX:

  1. contains the web methods
  2. validates the request params
  3. calls the DLL method

DLL:

  1. creates the database connection (hardcoded constants for the database server/user/password)
  2. selects data from database
  3. creates some objects with that data
  4. closes the connection.
  5. returns those objects

AMSX:

  1. process the returned objects from the DLL and returns them.

Should I create the connection in the web methods and store those parameters in a application or session variable, instead of creating them in the dll methods?

Thank you for your help

klautern
  • 129
  • 3
  • 7
  • 26
  • 2
    Isolate everything from the connection and the DataAccessLayer, see my answer here: http://stackoverflow.com/a/7474357/559144 you should have some classes in the ClassLibrary (DAL) which create the connection and use the EF or ADO.NET or whatever Data Access technology and do not share it or expose it to other layers. from your web services ASMX or WCF, you will create an instance of the Business Logic classes which will create an instance of the DAL classes and use their methods without explicitely opening a connection. – Davide Piras Jan 23 '12 at 11:42

1 Answers1

0

As advised in the comment from Davide if you are not using something like NHibernate or MS Entity Framework then it is arguably best practice to separate the Business Logic Layer from the Data Access Layer. The benefits are well documented including separation of concerns, Testing and allowing the DAL to be cross platform/system agnostic.

1.creates the database connection (hardcoded constants for the database server/user/password)

This is a very bad practice and can lead to a wide variety of security and deployment issues.

My question is about where to create the connection to the database, and how to configure the server/user/pass parameters in an external configuration file but not to be reading it each time I have to connect to the database.

The best and most convenient place to store the database connection string in the ConnectionString section of the App.config or Web.Config file, if you create a static property to expose the connection string from the config file then you do not need to read the configuration setting every time.

private static readonly string connectionString = ConfigurationManager.ConnectionStrings["MyConnectionString"].ConnectionString;

Should I create the connection in the web methods and store those parameters in a application or session variable, instead of creating them in the dll methods?

The short answer is no, the API you are exposing for your Web Service should do only what it is designed for, exposing the underlying business object from the Data Access Layer.

Community
  • 1
  • 1
Lloyd
  • 2,932
  • 2
  • 22
  • 18