2012-01-05 6 views
6

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

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

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

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

Вариант1

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

    } 
} 

// usage 
BllCustomer.GetCustomers(); 

Вариант2

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(); 
+0

Почему люди должны настаивать на том, чтобы не высказывать свое мнение по этому вопросу, я просто не могу понять. возможно, они не могут видеть эту тему по многим другим вопросам. да, я разговариваю сам с собой. – Fer

ответ

1

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

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

+0

благодарит за ваше мнение. Что вы думаете о варианте 4? – Fer

+0

После прочтения вопроса первое, о чем я думал, были проблемы с насмешкой. Приобретенный для этого и информация о контейнерах IoC – Mike

0

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

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

+0

вы сказали, что выберете вариант 2. что вы думаете о разнице между вариантом 1 и вариантом 2? они легки в использовании и статичны. почему бы не выбрать вариант 1? – Fer

+0

Я не использую вариант 1, потому что он слишком жесткий. Со статическим классом все ваши члены должны быть статическими. Более типично иметь нестатический класс со статическими членами, чем статический класс. Вы все равно можете создать экземпляр с параметром 2, но вы застряли со статическим классом с опцией 1. Идите с тем, что проще всего. Кроме того, вариант 1/2 не идеален для модульного тестирования, но если у вас мало таких методов, то модульное тестирование в любом случае не обязательно. Большая часть моей логики находится в хранимых процедурах, зависит. –

0

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

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