В EF 4.0, является ли статический класс для получения dbcontext хорошим способом?

Question

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

Этот GetEntity() возвращает контекст.В методе GetEntity у меня динамическое соединение.Когда кто-то заходит на мою страницу входа, ему нужно указать номер базы данных + имя пользователя + пароль.Я храню имя базы данных в Session["DBName"].

public static class EntityFactory
    {
        public static DBEntities GetEntity()
        {
            var scsb = new SqlConnectionStringBuilder();

            scsb.DataSource = ConfigurationManager.AppSettings["DataSource"];

            scsb.InitialCatalog = "db1";
            scsb.MultipleActiveResultSets = true;
            scsb.IntegratedSecurity = true;
            if (HttpContext.Current.Session["DBName"] == null)
            {
                HttpContext.Current.Response.Redirect("/Account/Step1");
            }
            else 
            {
                scsb.InitialCatalog = HttpContext.Current.Session["DBName"].ToString(); 
            }

            var builder = new EntityConnectionStringBuilder();

            builder.Metadata = "res://*/nms.bin.Models.DBModel.csdl|res://*/nms.bin.Models.DBModel.ssdl|res://*/nms.bin.Models.DBModel.msl";
            builder.Provider = "System.Data.SqlClient";
            builder.ProviderConnectionString = scsb.ConnectionString;
            DBEntities db = new DBEntities(builder.ConnectionString);
            return db;
        }

Когда я хочу получить DBContext в качестве примера в контроллере, мне просто нужно сделать EntityFactory.GetEntity(), и это возвращает мне контекст БД.

1. Правильно ли это, как я это делаю
2. Может ли это быть проблемой, если одновременно регистрируются 20 клиентов, но с другим именем dbname.
3. На данный момент,Я не использую никакой утилизации, это проблема?Основываясь на моем EntityFactory классе, могу ли я сделать глобальный одноразовый инструмент в этом классе, который будет вызываться автоматически.(Я думаю о методе descrutor).

Answer 1

Фабричный метод static может быть трудно смоделировать для модульного тестирования.Так, например, в вашем контроллере, если бы у вас было:

public void SomeControllerMethod()
{
    var entities = EntityFactory.GetEntity();
    return entities.Something // ... get whatever data...
}

Тогда как бы вы использовали фиктивный контекст данных в модульном тесте?Это было бы сложно сделать.Было бы лучше «внедрить» ваш контекст в ваш контроллер, обычно через конструктор (прочитайте статью в Википедии о « принцип инверсии зависимостей », если вы не знакомы с концепцией), например:

public class SomeController
{
    private readonly IDBEntities entities;

    // db context passed in through constructor,
    // to decouple the controller from the backing implementation.
    public void SomeController(IDBEntities entities)
    {
        this.entities = entities;
    }
}

И затем использовать методы контроллеров, которые передаются в ссылке.Таким образом, вы можете использовать инструмент внедрения зависимостей, чтобы получить соответствующий контекст БД, или передать имитируемый контекст.

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

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

Я обычно заканчиваю тем, что использую MVC3 с EntityFramework Code-Во-первых, что довольно неплохо, и вы можете смоделировать большую часть слоя данных с помощью List<T> вместо реальной базы данных, вы можете «загружать» и «сохранять» записи в списках в памяти и никогда не трогать реальную базу данных.

Answer 2

по порядку:

1. Вы можете улучшить его, передав GetEntity() всю необходимую информацию (например, имя базы данных, имя пользователя и пароль). Как сейчас, статический метод тесно связан с сеансом. Удалите сеанс из метода.

2. Это не должно быть так, как Сессия для пользователя.

3. Если DBEntities наследуется от DbContext, вы можете вызвать Dispose после использования объекта. Es: dbEntitiesObj.Dispose();