Должен ли я каждый раз создавать новый объект или создавать отдельный объект? - PullRequest
0 голосов
/ 07 января 2011

Я использую asp.net mvc и каркас сущностей. У нас есть уровень доступа к данным и бизнес-уровень. Теперь, поскольку доступ к данным выполняет все запросы, мне нужно создать объект доступа к данным в классах бизнес-уровня. Теперь я не уверен, должен ли я создавать только один объект или каждый раз создавать его локально. Вот пример -

Первый путь -

class Employee_Business
{
    public Employees GetEmployee()
    {
        DataAccess dao= new DataAccess();
        return dao.GetEmployees();
    }

    public Employee GetEmployee(int id)
    {
        DataAccess dao= new DataAccess();
        return dao.GetEmployee(id);
    }
}

Второй путь -

class Employee_Business
{
    DataAccess dao;
    public Employee_Business()
    {
        dao = new DataAccess()
    }

    public Employees GetEmployee()
    {
        return dao.GetEmployees();
    }

    public Employee GetEmployee(int id)
    {
        return dao.GetEmployee(id);
    }
}

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

Ответы [ 4 ]

1 голос
/ 07 января 2011

Из двух предоставленных вами списков вы должны использовать второй. Вам не нужно новое соединение (или контекст) для каждого запроса (если вы делаете запрос более одного раза в запросе), но вы должны создать новый экземпляр класса Employee_Business для каждого запроса. (Итак, без синглетонов для связи ...)

1 голос
/ 07 января 2011

Вы должны рассмотреть, как работают веб-приложения.Ваше приложение будет обслуживать несколько запросов, вполне вероятно, одновременно, и в этом случае вам нужно подумать, как будет использоваться ваш класс:

  1. Если класс выполняет только для чтения операции, вы, вероятно, можете использовать его как статический экземпляр, не беспокоясь об управлении потоками.
  2. Если класс выполняет запись операций, которые могут изменить его внутреннее состояние ,тогда вам нужно убедиться, что если он статический, он имеет мьютексы / мониторы / блокировки, где это необходимо, чтобы гарантировать выполнение атомарных операций.
  3. Если класс выполняет запись операций, которые не изменяйте его внутреннее состояние, вы, вероятно, можете использовать его в качестве статического экземпляра, не беспокоясь об управлении потоками.

При проектировании типов полезно учитывать эти сценарии.

1 голос
/ 07 января 2011

Каждый запрос требует отдельного подключения к базе данных, поскольку веб-приложение является многопоточным. Несколько запросов могут выполняться в отдельных потоках одновременно, и каждому потоку требуется собственное подключение к базе данных.

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

Создание нового экземпляра объекта для каждого запроса - это просто самое простое решение. Можно использовать одноэлементный класс или статические методы, но тогда вам нужно управлять соединениями, чтобы каждый запрос по-прежнему использовал свое собственное соединение.

1 голос
/ 07 января 2011

Если бы я был на вашем месте, я бы серьезно изучил схему «Единица работы».Это должно довольно тщательно позаботиться о вашем вопросе:

Шаблоны архитектуры корпоративных приложений: Единица работы

На самом деле сводится к тому, что каждый набор операцийвы выполняете через ваш уровень доступа к данным действительно должны быть частью единой единицы работы.Эта единица работы связывает все операции вместе и гарантирует, что все происходит синхронно.

Существует множество примеров шаблона единицы работы в .NET с использованием Entity Framework, которые вы должны быть в состоянии адаптировать для соответствия требованиям.ваши потребности.

...