Saturday, 24 August 2013

N-Layer/N-Tier error handling design

N-Layer/N-Tier error handling design

Out team is building an N-Tier application that will handle a lot of
database and network methods.
Basically we designed the following layers (from bottom to up):
Data layer: Can be Oracle or SQL (basically an EF entity and context
auto-generated using Database First) Persistent layer: Handle the Data
tier. We have a persistent tier for Oracle and another for SQL with some
small changes between them (we would like to refactory that in future to
have a single code - ideas accepted). Business layer: This is handling
specific application logic.
Above that we can have a presentation layers (ASP.NET App), an API that
calls directly business functions, a network agent that will allow
business requests from network and so on.
We are having doubts regarding the error handling mechanism. We decided
that all exceptions are threated on business layers, so this is the only
place where I have try/catch statements.
Our point is we don´t want the app users to get rid of exceptions, but
they need to know the status of operations. We created a ReturnStatus
class that looks like:
public class ReturnStatus
{
public enum ReturnStatusTypes : int { Success, Failure, Unknown }
public ReturnStatusTypes Status;
public int MessageCode;
public string Message;
/// <summary>
/// Class constructor
/// </summary>
public ReturnStatus()
{
Status = ReturnStatusTypes.Unknown;
MessageCode = 0;
Message = "";
}
/// <summary>
/// Class constructor
/// </summary>
/// <param name="status">Status</param>
/// <param name="message">Message</param>
public ReturnStatus(ReturnStatusTypes status, int msgCode)
{
Status = status;
MessageCode = msgCode;
Message = ErrorMessages.ResourceManager.GetString("ErrorCode" +
msgCode);
}
}
The Message property is localizable depending on the App culture set before.
We would like that every call to a Business layer method has a
ReturnStatus. That can be logged into ASP.NET status bar, returned to the
API or sent over network to the other apps. The prob is that most of our
business classes returns data, so we need to find a way to return status
and data together to the consuming actors.
Our staff is considering: a) Using tuples on every call. That seens not to
be the recommended way. b) Throw an expection: not compliant with our
architecture. c) Using out ReturnStatus on every call: Considered an
option, even looking old fashioned. d) Keeping a last error object
somewhere, so the call can return data directly and user may call
lastactionstatus to get this error. Our point is: we don´t know where to
store that last error data. On a singleton class ?
The solution must be uniform between all business methods.
What would you recomend for the best method and how to implement it.

No comments:

Post a Comment