Click here to Skip to main content
15,908,842 members
Home / Discussions / Design and Architecture
   

Design and Architecture

 
QuestionSoftware development Pin
systemexpertise1-Jan-09 18:26
systemexpertise1-Jan-09 18:26 
AnswerRe: Software development Pin
Cosmic Egg10-Jan-09 3:29
Cosmic Egg10-Jan-09 3:29 
QuestionStylesheet in VS2008 Pin
sarang_k30-Dec-08 19:01
sarang_k30-Dec-08 19:01 
AnswerRe: Stylesheet in VS2008 Pin
CodingYoshi4-Jan-09 15:45
CodingYoshi4-Jan-09 15:45 
QuestionException Hierarchy Pin
CodingYoshi29-Dec-08 11:27
CodingYoshi29-Dec-08 11:27 
GeneralRe: Exception Hierarchy Pin
Luc Pattyn29-Dec-08 15:12
sitebuilderLuc Pattyn29-Dec-08 15:12 
GeneralRe: Exception Hierarchy Pin
CodingYoshi30-Dec-08 3:18
CodingYoshi30-Dec-08 3:18 
AnswerRe: Exception Hierarchy Pin
Jon Rista6-Jan-09 8:48
Jon Rista6-Jan-09 8:48 
Before I go into a discussion on proper exception management, I need to bring up a fundamental architectural issue. There are a variety of architectural styles, and usually each team or architect will choose the style they like best. However, an extensive amount of research has gone into how "effective" an architecture is in enabling developers, testers, etc. develop a deliverable product. So, I'm going to throw out one of the rules of effective design here: Isolation.

Your current design is a very dependant design. Your Person class is tightly coupled in two ways. First off, its tightly coupled to a specific concrete implementation of the PersonManager. Second, its tightly coupled to a specific persistance mechanism. Both couplings are bad, no other way to put it really. If we look at some of the most effective software development methodologies today, DDD and TDD will rise to the top. Both advocate the isolation of classes from each other, and both advocate the use of dependancy injection to improve decoupling (help achieve 'loose coupling'). Your Person entity should be simple, and should not be aware of the persistance object (PersonManager). This means Person can't save itself, so the save operation goes into a person 'service'. You would end up with something like this:

// Service layer
class PersonService
{
    Person Load(int id)
    {
        // Validate ID is greater than 0
        PersonManager mgr = new PersonManager();
        Person person = mgr.GetByID(id);

        return person;
    }

    void Save(Person person)
    {
        PersonManager mgr = new PersonManager();
        
        if (person.ID <= 0)
        {
            mgr.Insert(person);
        }
        else
        {
            mgr.Update(person);
        }
    }
}

// Business Layer
class Person
{
    int ID { get; set; }
    string Name { get; set; }
}

// Data Access Layer
class PersonManager // This is really a 'Repository' (http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/10/08/the-repository-pattern.aspx)
{
    Person GetByID(int id)
    {
        // Load a person object from the database
    }

    void Update(Person person)
    {
        // Update a person in the database
    }

    Person Insert(Person person)
    {
        // Insert a person into the database, returning the person with an updated Key (ID in this case)
    }

    void Delete(Person person)
    {
        // Delete a person from the database
    }
}


With the above, your system is appropriately decoupled. Your exception management, along with the bulk of your business logic, and particularly interaction with persistance logic, should reside primarily in your service layer. This greatly simplifies your data access code and your entity...neigher one need to handle exceptions...they just throw them. If, for some reason, the service layer can not resolve or recover from an exception, then the exception should bubble up to your presentation layer, where you could handle it explcitly, or in most cases, just let the default handler deal with it. To keep your exception management simple in the presentation layer, you could follow a general rule of always wrapping all exceptions that bubble up from the service layer in a ServiceException. Ultimately, however, you will only have two areas where exceptions will be handled...your service layer and your presentation layer.

As for exception resolution...if, and I stress IF, you can handle the exception automatically, then the resolution strategy should also reside in your service layer. Generally speaking, exceptions indicate some broken state that is preventing a process from completing successfully...which usually requires user intervention. If you have some alternate path for accomplishing something, that alternate path should be attempted in the service, and nowhere else. But I wouldn't stick a save operation in a loop and try it 5 times before finally bubbling an exception up...thats just wasting resources, because if it failed the first time, it failed. If there is a chance it could succeed during a series of successive tries, then it sounds like you have concurrency issues that should be solved at a lower level to prevent such exceptions from ever occurring in the first place.
GeneralRe: Exception Hierarchy Pin
Leftyfarrell6-Jan-09 13:29
Leftyfarrell6-Jan-09 13:29 
GeneralRe: Exception Hierarchy Pin
Jon Rista6-Jan-09 17:31
Jon Rista6-Jan-09 17:31 
GeneralRe: Exception Hierarchy Pin
Curtis Schlak.25-Feb-09 9:02
Curtis Schlak.25-Feb-09 9:02 
AnswerRe: Exception Hierarchy Pin
Curtis Schlak.25-Feb-09 9:20
Curtis Schlak.25-Feb-09 9:20 
QuestionWho can show me the process and method of Scrum? Pin
Tal Rasha's Guardianship18-Dec-08 21:32
Tal Rasha's Guardianship18-Dec-08 21:32 
AnswerRe: Who can show me the process and method of Scrum? Pin
Ashfield18-Dec-08 22:01
Ashfield18-Dec-08 22:01 
GeneralRe: Who can show me the process and method of Scrum? Pin
Tal Rasha's Guardianship22-Dec-08 17:17
Tal Rasha's Guardianship22-Dec-08 17:17 
GeneralRe: Who can show me the process and method of Scrum? Pin
Ashfield26-Dec-08 22:40
Ashfield26-Dec-08 22:40 
QuestionArchitecture that supports Unit Testing - Is there such a thing as Too Many Interfaces? Pin
Leftyfarrell18-Dec-08 4:42
Leftyfarrell18-Dec-08 4:42 
AnswerRe: Architecture that supports Unit Testing - Is there such a thing as Too Many Interfaces? Pin
led mike19-Dec-08 7:40
led mike19-Dec-08 7:40 
QuestionRe: Architecture that supports Unit Testing - Is there such a thing as Too Many Interfaces? Pin
Leftyfarrell19-Dec-08 8:08
Leftyfarrell19-Dec-08 8:08 
AnswerRe: Architecture that supports Unit Testing - Is there such a thing as Too Many Interfaces? Pin
Giorgi Dalakishvili19-Dec-08 8:19
mentorGiorgi Dalakishvili19-Dec-08 8:19 
AnswerRe: Architecture that supports Unit Testing - Is there such a thing as Too Many Interfaces? Pin
Mark Churchill22-Dec-08 18:42
Mark Churchill22-Dec-08 18:42 
AnswerRe: Architecture that supports Unit Testing - Is there such a thing as Too Many Interfaces? Pin
CodingYoshi25-Dec-08 21:03
CodingYoshi25-Dec-08 21:03 
AnswerRe: Architecture that supports Unit Testing - Is there such a thing as Too Many Interfaces? [modified] Pin
Jon Rista6-Jan-09 9:01
Jon Rista6-Jan-09 9:01 
GeneralRe: Architecture that supports Unit Testing - Is there such a thing as Too Many Interfaces? Pin
Leftyfarrell6-Jan-09 13:10
Leftyfarrell6-Jan-09 13:10 
GeneralRe: Architecture that supports Unit Testing - Is there such a thing as Too Many Interfaces? Pin
Jon Rista6-Jan-09 13:36
Jon Rista6-Jan-09 13:36 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.