Passing results of operations in a Data Access Layer back to calling layers? Best practice?
Posted on 2009-04-20
i have an application where I am trying to adhere to n-Tier architecture principles. I want to keep a fairly strict pathway to my data access layer for both input and output. Input is passed through typed parameters passed from the calling routines in my business logic layer, but I have a variety of possible return values that need to get passed back to the caller. Some routines only return a boolean indicating the success of an operation, whereas others return data objects,etc.
What I would like to do is create a generic return object that all my DAL routines could make use of, and give calling routines a consistent interface for the return values. I would like this object to contain the results of each DAL operation. If an exception occurs, I want to be able to pass the details of the exception back to the caller. If a data row or a data table needs to be passed back to the caller, I would like to be able to do it through this generic object.
My tentative idea is to create a class that would contain a boolean property indicating the success of the DAL operation, a custom exception object, and a generic return object for any data that needs to be passed back to the caller. I could then load this return object with the appropriate information and return it to the caller.
My question is whether or not this is considered a 'bast practice' in the n-Tier realm? In the past, I have just handled the results of various routines locally, but with a layered architecture that approach seems to yield hard-to-maintain spaghetti code.