Как я могу улучшить этот код без использования статического или синглтон?


Я использовал, чтобы использовать статические или Singleton для класса даль. Однако, я читал некоторые статьи говорят, что синглтон-это зло и его следует избегать. Поэтому я пытаюсь переписать мой код вроде этого:

public class CustomerBLL
{
    private CustomerHelper helper = new CustomerHelper();
    private CustomerDAL dal = new CustomerDAL();

    public void Method1(string param)
    {
        dal.Method1(param);
    }

    public void Method2(string param)
    {
        dal.Method2(param);
    }

    public void MethodA(int param)
    {
        helper.MethodA(param);
    }
}

Как я могу улучшить этот код? Он никогда не смотрит прямо.



631
2
задан 22 ноября 2011 в 02:11 Источник Поделиться
Комментарии
1 ответ

Я считаю, что некоторые обобщения должны быть сделаны слегка. т. е. о том, что синглтоны это зло вообще не является точным, а в некоторых случаях Синглтон-это правильное (и, возможно, единственное) решение. И да, я считаю, что это один из чрезмерно злоупотреблять моделей там. Получили, что из пути, я двигаюсь, чтобы ответить на ваш вопрос.

Из кода примера, который вы представили, то становится совершенно ясно, что ваш CustomerBLL нет бизнес-логики и выступает лишь в качестве фасада на вершине доступа к данным и другие вспомогательные классы. Фасады должны быть по природе без гражданства.

Сказав это, я предложу два варианта на основе тестирования и требования к развязке.

Если вы хотите, чтобы вы CustomerBLL тестирования и отделить его от CustomerHelper и CustomerDAL конкрементов и замещения их абстракциями, то один хороший дизайн аксессуара будет вводить CustomerHelper и CustomerDAL зависимостей в CustomerBLL класса, который позволяет издеваться и заглушки доступа к данным и вспомогательные классы и сосредоточиться на тестировании другие модули, которые потребляют CustomerBLL класс. Вы достигаете, что через extraxcting интерфейсы, конечно.

Вот пример того, как код будет выглядеть, если мы введем зависимостей через конструктор, обратите внимание, что ваш CustomerBLL фасад будет экземпляра класса, т. е. без статических методов будет раскрыт.

public class CustomerBLL
{
private readonly ICustomerHelper _helper;
private readonly ICustomerDAL _dal;

// default constructor initializes the concrete dependencies
public CustomerBLL()
:this(new CustomerHelper(), new CustomerDAL())
{}

// constructor to inject stubbed dependencies for testing purposes
public CustomerBLL(ICustomerHelper customerHelper, ICustomerDAL customerDal)
{
_helper = customerHelper;
_dal = customerDal;
}

public void Method1(string param)
{
_dal.Method1(param);
}

public void Method2(string param)
{
_dal.Method2(param);
}

public void MethodA(int param)
{
_helper.MethodA(param);
}
}

public interface ICustomerDAL
{
void Method1(string s);
void Method2(string s);
}

public interface ICustomerHelper
{
void MethodA(int i);
}

internal class CustomerDAL : ICustomerDAL
{
public void Method1(string s)
{
}

public void Method2(string s)
{
}
}

internal class CustomerHelper : ICustomerHelper
{
public void MethodA(int i)
{
}
}

Если, с другой стороны, тестирование не является проблемой на всех, тогда вы можете продолжить потребляя CustomerBLL как фасад процедурным способом с помощью статических методов (хотя я предпочитаю контролепригодность подход, но это не каждому по чашке чая).

Здесь вы заметили, я удалил частные поля, которые содержат ссылки на помощника и дал занятия, потому что мы хотим развивать, что CustomerBLL фасад является лицом без гражданства.

public class CustomerFacade
{
public static void Method1(string param)
{
new CustomerDAL().Method1(param);
}

public static void Method2(string param)
{
new CustomerDAL().Method2(param);
}

public static void MethodA(int param)
{
new CustomerHelper().MethodA(param);
}
}

Я видел и использовал оба подхода, на мой скромный взгляд, они оба действуют в зависимости от сценария использования. В общем я за проверяемый дизайн и отделенных модулей и поэтому я предложил первый подход.

6
ответ дан 22 ноября 2011 в 05:11 Источник Поделиться