misterstick
Programmer
out of ignorance and hubris over the last month or so i've pulled an n-tier application out of my special magic pocket.
i thought i'd understood the general principles of it all, but a brisk reading of this microsoft article on mimicking ado in .net gives me pause for thought.
i fear that what i thought was the data access layer is, in fact, merely a wrapper for the various data access protocols.
my question, therefore, is how, and where, should sql strings be stored and handled in your bog-standard n-tier architecture?
i've got them in the "business" layer currently. should they be moved to the "data access" layer? should i create a new layer in between "business" and "data access" that actually handles the data access?
should it all be done with stored procedures, moving the actual data access into the database?
mr s. <
i thought i'd understood the general principles of it all, but a brisk reading of this microsoft article on mimicking ado in .net gives me pause for thought.
i fear that what i thought was the data access layer is, in fact, merely a wrapper for the various data access protocols.
my question, therefore, is how, and where, should sql strings be stored and handled in your bog-standard n-tier architecture?
i've got them in the "business" layer currently. should they be moved to the "data access" layer? should i create a new layer in between "business" and "data access" that actually handles the data access?
should it all be done with stored procedures, moving the actual data access into the database?
mr s. <