маркировка классов BLL как статических или? - PullRequest
6 голосов
/ 05 января 2012

У меня уже есть многоуровневый дизайн доступа к данным, который работает хорошо. Но я не знаю, является ли это наиболее подходящей реализацией или нет.
я просто хочу знать, что классы или методы BLL должны быть статическими, или они должны быть классами, которые имеют только один экземпляр?
В то же время мне не нужно сериализовать BLL-классы, чтобы использовать его в таком дизайне SOA. Но я не знаю, что принесет эта функция.
Посмотрите на следующие варианты:

  1. Классы и методы BLL являются статическими
  2. Классы BLL не являются статичными, но их методы являются статическими
  3. Классы BLL не являются ни статическими, ни их методами. Приложение должно каждый раз создавать класс BLL для доступа к его методам.
  4. Классы BLL не являются ни статическими, ни их методами. Но есть только один экземпляр каждого класса BLL. И приложение использует эти статические экземпляры, чтобы использовать методы BLL.

Какой из них наиболее эффективен в основном по производительности и дизайну?

РЕДАКТИРОВАТЬ:

Option1

public static class BllCustomer
{
    public static List<ModelCustomer> GetCustomers()
    {

    }
}

// usage
BllCustomer.GetCustomers();

Option2

public class BllCustomer
{
    public static List<ModelCustomer> GetCustomers()
    {

    }
}

// usage
BllCustomer.GetCustomers();

Вариант3

public class BllCustomer
{
    public List<ModelCustomer> GetCustomers()
    {

    }
}

// usage
BllCustomer bllCustomer = new BllCustomer();
bllCustomer.GetCustomers();

ОПЦИЯ4

public class BllCustomer
{
    public List<ModelCustomer> GetCustomer()
    {

    }
}

// usage
public static BllCustomer s_BllCustomer = new BllCustomer();
// whenever needed
s_BllCustomer.GetCustomer();

Ответы [ 3 ]

1 голос
/ 06 января 2012

Сериализация ваших классов Domain / BusinessLogicLayer звучит немного необычно, поскольку уровень вашего домена обычно содержит бизнес-правила и сложную логику обработки. Обычно вы хотите сериализовать ваши классы DataTransformation / POCO.

Существуют незначительные performance различия между статическими или конкретными классами / методами. Я бы отказался от статических классов и методов для вашей основной бизнес-логики, так как их может быть трудно смоделировать / модульное тестирование, плюс не работать с контейнерами IoC. Поэтому, учитывая это, я бы порекомендовал вариант 3, как вы это объяснили. Здесь также есть несколько чрезвычайно полезных ответов здесь .

0 голосов
/ 25 января 2012

Я лично строил системы, используя множество этих методов. В конце концов, я должен был понять, что слишком умен, потому что самая простая техника на самом деле самая гибкая. Если вы испытываете желание сделать что-то статическим, потому что это кажется менее трудоемким и, следовательно, «более эффективным», то вы делаете это по неправильным причинам.

Я предлагаю НЕ делать класс или методы статичными. Причина в том, что я пришел к выводу, что такие шаблоны, как DDD и Dependency Injection (IoC), очень ценны. Например, как бы вы протестировали какой-либо код веб-сайта или приложения, который использует этот BLL? Как правило, вы хотели бы «смоделировать» свой BLL, чтобы он дал предсказуемые результаты. Вам будет трудно делать это со статическими классами.

0 голосов
/ 24 января 2012

Для большей производительности и простоты использования второй вариант имеет смысл.Я использую вариант 2 сейчас и не столкнулся с какими-либо проблемами.Большинство из них просто содержат строку, которая вызывает DAL, а затем другую строку, которая регистрируется с помощью log4net.У большинства из них нет бизнес-логики.

Однако я использую это с ASP.NET.

...