Использование статических классов в Business Logic Layer - PullRequest
Новая
       37

Использование статических классов в Business Logic Layer

4 голосов
/ 15 сентября 2011

Я знаю, что ответ на мой вопрос может включать выбор конкретного подхода, но я пытаюсь объяснить, что я пытаюсь выяснить, с деталями:

Рассмотрим простое трехслойное приложение (DAL, BLL, PL).
DAL использует EF 4.1 Code-First и доступ к данным обернут в хранилище.

Прямо сейчас, в BLL, у меня есть Manager классы. (например, UserManager, ProductManager), которые все происходят от BaseManager. Почти каждый метод в моих классах Manager принимает связанную сущность в качестве параметра и выполняет с ним соответствующие операции. например в UserManager (псевдокод): 

public bool AddPermission(User user, PermissionItem permission)
{
    this.repository.Add(permission);
    this.save();
}

Вопрос: мои классы менеджера не нуждаются в создании экземпляров. они могут быть определены как статические.
Но если я определю их как статические, я должен создать свои общие методы и члены (например, repository и пару других членов) в каждом классе (я не хочу определять такие элементы, как репозиторий, как статические).

Так вы предлагаете мне изменить классы Manager, которые действительно должны быть статическими, на статические классы? или можно использовать их как есть?

Ответы [ 3 ]

4 голосов
/ 15 сентября 2011

imho статические классы являются не чем иным, как контейнерами для функций (а не реальных объектов).Разница в том, что нестатические классы могут быть получены и получить их зависимости через конструктор.

Попробуйте написать правильные тесты для статического класса.

Возможно, вы не предполагали, что они будутсегодня, а как насчет завтра?Если вы измените их на статические, вам придется реорганизовать весь свой зависимый код, чтобы сделать их статическими.

Я бы лучше начал использовать инверсию контейнера управления для управления их созданием и экземплярами.

2 голосов
/ 15 сентября 2011

Не вижу смысла делать их статичными.Насколько я вижу, это только усложнит API и реализацию.И откуда ваши посетители смогут получить хранилище?Должны ли они искать его для каждого звонка?Это расточительно.Гораздо лучше посмотреть его один раз и сохранить в менеджере.Вот для чего нужны переменные экземпляра.

0 голосов
/ 15 сентября 2011

Мне нравится создавать статический «каталог» (правильное имя для этого объекта - фактически репозиторий), который содержит все мои экземпляры. Например: 

public static Class BusinessRepository
{
    private static Users users = new Users();

    public static Users Users
    {
        get
        {
            return users;
        }
    }
}

Класс BusinessRepository является статическим, но Users - это объект экземпляра, содержащийся в нем. Это может быть получено следующим образом: 

BusinessRepository.Users.DoSomething();

Таким образом, вы получаете возможность сохранять экземпляры объектов и все преимущества, которые они приносят, со статическим доступом к ним.

Многие люди не согласны с такими «глобальными переменными», как они их будут называть, но это ваше суждение. Похоже, вы уже приняли решение, что вы довольны этим, поскольку вы уже говорите о статических классах.

...