Best Practices for a Data Access Layer
Best Practice for a Data Access Layer:
I am creating a class-injected data layer of the type: public List<T> GetData<T>(string cnn, string proc, string args)
where T is the class-definition of the data to be returned
cnn is the name of the database connection
proc is the name of the retrieval technique (stored proc)
args is a class-driven list for passing parameters
The goal here was to isolate the retrieval(obviously) from the middle tier and to use base-class definitions to describe the data.
Of course I may be creating a base-class runaway problem based on the number of dataset descriptions the team creates,
Does this sound like a good approach or is there a better way?
Thanks in advance
I am creating a class-injected data layer of the type: public List<T> GetData<T>(string cnn, string proc, string args)
where T is the class-definition of the data to be returned
cnn is the name of the database connection
proc is the name of the retrieval technique (stored proc)
args is a class-driven list for passing parameters
The goal here was to isolate the retrieval(obviously) from the middle tier and to use base-class definitions to describe the data.
Of course I may be creating a base-class runaway problem based on the number of dataset descriptions the team creates,
Does this sound like a good approach or is there a better way?
Thanks in advance
kaufmed
Off-topic: Don't use abbreviations for variables names. You're not paying by the character, and abbreviations only mean something to the person who created them.
Expand on consumers (clients calling code).
Many times code is far simpler when written as an API, rather than trying to embed complex C/C#/C++ code into every client.
Many times code is far simpler when written as an API, rather than trying to embed complex C/C#/C++ code into every client.
In addition to kaufmed - when using full names try not to use duplicate names of existing classes (using a small letter instead of capital can often get around that).
ASKER
So far thanks for the comments here. The actual layer will consume a web api to fetch the actual data. this wrapper is just to try to eliminate multiple api methods that return variations of data based upon :
-filter parameters
-data firnatting differences
Currently we have over 100 reports and at least that many stored procedures.
-filter parameters
-data firnatting differences
Currently we have over 100 reports and at least that many stored procedures.
What does your architecture look like? What layers do you have involved, and how are they inter-dependent?
ASKER
The architecture is pretty unknown at the moment on the data delivery side.
The institution is moving to Oracle but the Vendor's app is in the Amazon Cloud.
I may need to write some web services that join together, thee disparate, data architectures and delivery it to the frontend app.
In the meantime I am writing this DAL that will hide the problematic data manipulation by calling a wrapper web service that I mentioned above. The DAL is intended to eliminate multiple calls within the middle tier that faces the front end.
Client
--------------
DAL (still within Client App for now but will be an API in itself)
--------------
Web services that call the disparate data sources.
I didn't want to write a lot of repetitive code so I came up with this approach.
In CORE2 some of the team are looking at examples but these examples seem to tie each method to the type of parameters and dataset return to the caller.
I'd like to get validation for my approach. yes, syntactically it can and will be polished.
I know all approaches have shortcomings when used to the extreme.
The shortcomings I see with this approach are that numerous base classes have to be created (and shared) with the backend so that data delivery can be mapped well.
I am wondering if there are others. I have no architectural documents as of yet.
The institution is moving to Oracle but the Vendor's app is in the Amazon Cloud.
I may need to write some web services that join together, thee disparate, data architectures and delivery it to the frontend app.
In the meantime I am writing this DAL that will hide the problematic data manipulation by calling a wrapper web service that I mentioned above. The DAL is intended to eliminate multiple calls within the middle tier that faces the front end.
Client
--------------
DAL (still within Client App for now but will be an API in itself)
--------------
Web services that call the disparate data sources.
I didn't want to write a lot of repetitive code so I came up with this approach.
In CORE2 some of the team are looking at examples but these examples seem to tie each method to the type of parameters and dataset return to the caller.
I'd like to get validation for my approach. yes, syntactically it can and will be polished.
I know all approaches have shortcomings when used to the extreme.
The shortcomings I see with this approach are that numerous base classes have to be created (and shared) with the backend so that data delivery can be mapped well.
I am wondering if there are others. I have no architectural documents as of yet.
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.