Sam
Sam

Reputation: 943

Data access layer design

I have a web app and a console application accessing a db. The db has 2 tables (A, B) one of which (A) is specific to the web app. When writing a data access layer, what is the best way to do it? Technically data access layer should provide access to all the data accessible. In doing so, methods to interact with A are exposed to the console application if we have single access layer. Does creating 2 access layers to 2 table in the same database makes any sense? What is a good way to do it?

Upvotes: 4

Views: 595

Answers (1)

Darren
Darren

Reputation: 70718

I would personally have the data access layer seperate in a class and 1 (or as many intermediate classes) to hold the business entities which would talk/get populated by the data access layer. The Console and Web application then talks to the business entity layer.

For instance:

Data Access Layer

Holds ALL connection information regarding the database, methods to execute stored procedures, functions and queries. This class would talk to Table A and Table B

Console 1 Entities

This would hold methods/properties that use the data access layer instance to retrieve the appropriate information. I.e.

public List<string> GetTableAContents() {
   var retVal = Data.RunStoredProcedure("sp_Table1Contents);
   return retVal;
}

Console Application

Console1Entity ce = new ConsoleEntity();
var contents = ce.GetTableAContents();

You would then make a new WebApplication entities class based upon what is relevant to that application. This would provide a three tier architecture.

Upvotes: 1

Related Questions