Хороша ли эта 4-уровневая архитектура? (Для меня важна обработка исключений :) - PullRequest
Новая
       41

Хороша ли эта 4-уровневая архитектура? (Для меня важна обработка исключений :)

0 голосов
/ 29 августа 2010

В моем приложении есть следующие слои:

  • Сущности
  • База данных (со ссылкой на сущности)
  • Бизнес (со ссылками на базы данных и сущности)
  • Пользовательский интерфейс (со ссылками Business и Entities)

Вот пример моих кодов:

  • Класс UserDAL на уровне базы данных: 
public class UsersDal
{
    databaseDataContext db;
    public UsersDal()
    {
        try
        {
            db = new databaseDataContext(ConnectToDatabase.GetConnectionString());
        }
        catch (Exception ex)
        {
            throw ex;
        }
    }
    public List<User> GetAllUsers()
    {
        try
        {
            return (from u in db.Users select u).ToList();
        }
        catch (Exception ex)
        {
            throw ex;
        }
    }

И так далее ...

В классе UserBLL на бизнес-уровне я пишу так: 

public class UsersBll
{
    UsersDal user;
    public UsersBll()
    {
        try
        {
            user = new UsersDal();
        }
        catch(Exception ex)
        {
            throw new ProjectException(Errors.CannotCreateObject, ex);
        }
    }
    public List<User> GetAllUsers()
    {
        try
        {
            return user.GetAllUsers();
        }
        catch(Exception ex)
        {
            throw new ProjectException(Errors.CannotReadData, ex);
        }
    }

И в пользовательском интерфейсе я пишу: 

    private void GetUsers()
    {
        try
        {
            UsersBll u = new UsersBll();
            datagrid.DataSource = u.GetAllUsers();
        }
        catch(ProjectException ex)
        {
            MessageBox(ex.UserMessage);// and also can show ex.InnerException.Message for more info
        }
    }

Ну, я использую именованный класс ProjectException, чтобы вызвать ошибку, содержащую созданное мной сообщение BLL и сообщение об исключении, которым ОС автоматически манипулирует.Также я создаю перечисление возможных ошибок, и словарь вот некоторые детали об этом: 

namespace Entities
{
    public enum Errors
    {
        CannotCreateObject,
        CannotReadData,
        CannotAdd,
        CannotEdit,
        CannotDelete,...
    }

[global::System.Serializable]
public class ProjectException : Exception
{
    public ProjectException(Errors er, Exception ex)
        : base(errors[er], ex)
    {
        currentEx = er;//er is Errors enum
    }
    static ProjectException()
    {
        errors = new Dictionary<Errors, string>();
        errors.Add(Errors.CannotCreateObject, "the application cannot connect to database!");
        errors.Add(Errors.CannotReadData, "the application cannot read data from database"); //...
    }
    public string UserMessage
    {
        get
        {
            try
            {
                return errors[currentEx];
            }
            catch
            {
                return "Unknown error!";
            }
        }
    }

Это хорошо?это работает для меня нормально.что ты думаешь?

1 Ответ

1 голос
/ 11 декабря 2011

В catch (ex) почти всегда неправильно делать throw ex;.Либо просто сделайте throw;, либо просто throw new whateverException("someMessage", ex);.Решение о том, использовать ли первую форму или последнюю, обычно зависит от того, пересекаете ли вы уровень приложения.Если AcmeServerDatabaseWrapper, который является производным от типа DatabaseWrapper, выполняет запрос, когда выбрасывается AcmeDatabaseTableNotFoundException, он должен перехватить его и переопределить как DatabaseWrapperTableNotFoundException (если такой тип существует) или как DatabaseWrapperOperationFailedException.Клиентский код, имеющий объект, полученный из DatabaseWrapper, должен иметь возможность знать, какие типы исключений будет генерировать этот объект, без необходимости знать, какой это тип объекта.Любое исключение, которое выходит из слоя базы данных без переноса, является исключением, которое клиентский код вряд ли сможет обработать разумно, но может ошибочно обработать (думая, что это произошло в контексте, отличном от того, где оно фактически произошло).

...