Работа с структурой сущности, предпочтительный способ?

Question

Предположим, мы создали модель Entities, какой способ работы с ней предпочтителен?Лично я не могу определиться ..

1. Использование ModelAdapter:

   public statiс Product[] GetProducts()
   {
           using(Entities ctx = new Entities())
           {
                   return ctx.Product.ToArray();
           }
   }
   
   
   
   Product[] ps = ModelAdapter.GetProducts();
   // ...
   ModelAdapter.UpdateProduct(p);
   

   • выглядит аккуратно;
   • , ноконтекст часто создается / освобождается, объекты теряют связь с контекстом;

2. Использование контекста на месте:

   using(Entities ctx = new Entities())
   {
           Product[] ps = ctx.Product.ToArray();
   
           // ...
   
           ctx.SaveChanges();
   }
   

   • действует
   • , но код становится беспорядочным

3. Смешанный режим, компромисс?

4. Методы расширения:

   using(Entities ctx = new Entities())
   {
       Product[] ps = ctx.GetProducts();
       // ...
       ctx.UpdateProduct(p);
   }
   

Собственно, сейчас яПопытка подхода № 4, реализация служебных методов как расширения контекста.Поэтому я могу использовать один контекст и делать много вызовов этому контексту.

Answer 1

При разработке веб-приложений я использовал общий контекст, который создается для каждого веб-запроса. Затем вы можете использовать свой подход ModelAdapter и сохранить инкапсуляцию, но при этом работать в том же контексте. Я использовал это много и не испытывал никаких проблем.

Answer 2

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

• Никогда не делитесь контекстом между запросами , используйте контекст для запроса, действия или метода в зависимости от ваших потребностей.
• Если вы хотите выполнить модульное тестирование своего приложения, вы можете обнаружить, что статические методы, а иногда и методы расширения могут быть проблемой. Но тестирование приложения с EF - это отдельная проблема .
• Если вы хотите изменить или вставить больше элементов в одну единицу работы, вы можете обнаружить, что контекст для метода - это не то, что вам нужно
• Многим разработчикам нравится использовать шаблон репозитория, чтобы отделить доступ к функциям EF от остальной части приложения. У него есть свои плюсы и минусы .

Answer 3

Как правило, я бы пошел на реализацию, где сложности работы с EF абстрагируются с помощью шаблона Repository , но контекст остается живым до тех пор, пока он мне нужен. (Сценарий 3)

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

Я думаю, что во многих отношениях ваш ModelAdapter также абстрагируется от сложностей EF, однако, основываясь на его статической природе, вы можете столкнуться с проблемами в параллельных сценариях, если решите сохранить ObjectContext. Способ его реализации теперь может не дать вам гибкости, необходимой для более сложных запросов (например, присоединение к Order <-> OrderDetail <-> Product).