Re: closing DataReader in another layer

Tech-Archive recommends: Speed Up your PC by fixing your registry

From: Nick Malik (nickmalik_at_hotmail.nospam.com)
Date: 11/26/04 

Date: Fri, 26 Nov 2004 07:55:50 GMT

> >
> > However, you might consider DataSets for a different reason: They
actually
> > can go across physical layers, not just logical ones.
> >
>
> I'd like to not even have to call the .Close on the reader in the business
> tier as it is easy to forget to do, especially down the road. With a
dataset
> its not a big deal since I can close the connection in the DAL before the
> dataset even gets returned and never have to worry about it in the buiness
> layer.

Hi Dan,

If you have truly seperated the data layer from the business layer, then you
really should use the dataset. A lot of folks pan the dataset because the
data is read into an object that gets passed around and it takes time to
load up the object. The same folks then encapsulate their data into an
object and, guess what, they pass it around, rarely adding much more
functionality to it than the dataset already has.

One thing that I have done, in my code, is to create an object that contains
a dataset. I pass my object into my DAL, which fills the contained dataset
with data. I then pass my object around, which as some additional
functionality for validating and enforcing business rules. When it comes
time to update the database, I pass my object back to the DAL, which then
uses the internal dataset to update the database. That way, I get the
functionality of the Dataset, plus the business rules enforcement of my
application, with a minimum of code to debug.

(I don't believe in re-inventing the wheel).

Hope this helps,
--- Nick

Relevant Pages

  • Re: "Business Logic / Rules should never be in the database or stored procedures"
    ... My primary role has served around the Oracle Applications environment and Oracle ... there exist a blend of business logic between the database and the application layer for ... Reason being that the database cannot process the business rules efficiently nor can they ... and do absolutely everything in the application layer. ...
    (comp.databases.oracle.misc)
  • Re: Design advice needed
    ... the addition of business rules, or to allow integration with other systems, ... There is a REASON for every layer of code. ... Seperating the database from the ... > In the implementation of the document I think about general functions ...
    (comp.object)
  • Re: Domain Model and Service Layer
    ... First I have a hard time reading the responses using the new Google's ... Services layer also known as application layer is a layer above domain ... the answer to your original question is to place the ... business rules live in the app layer. ...
    (comp.object)
  • Re: Biz Modeling - lets try again
    ... then people try to put it in one layer or place and argue about where ... Expert systems can apply complex business rules. ... "if parent has kids, disallow deletion of parent". ... and GUI business rules in the GUI. ...
    (comp.object)
  • Re: Possible bug in Calendar
    ... java.util.Calendar is essential to that project to coordinate the various time zones involved, including business rules as to due dates, intervals between document submissions and the like. ... providing the localized user interfaces, including selection of which business rules to apply, but in the core logic classes I *hope* your Dates are all represented in one particular time base and that when the chosen business rules say "x is three days after y" it just adds 3*86400*1000ms to some number somewhere under the hood. ... It's still happening in a layer not far beneath the UI layer. ... Because if you've got mixed time-zones in the core data representations you've got big trouble on the way. ...
    (comp.lang.java.programmer)