Самостоятельно отслеживаемые сущности против POCO Pure v. Проверка будущего (3 уровня) - PullRequest
Новая
       38

Самостоятельно отслеживаемые сущности против POCO Pure v. Проверка будущего (3 уровня)

0 голосов
/ 18 июля 2011

Это, очевидно, тема, которая обсуждалась много раз, однако мой угол подхода здесь немного другой. Насколько я понимаю, STE считается POCO (он никак не связан с EF dll), он просто содержит некоторые дополнительные «вещи» для обработки своего собственного отслеживания изменений. Предполагая следующие прикладные уровни: 

Proj.Web
Proj.Business
Proj.Model
Proj.DataAccess

Предполагая, что lazy loading не требуется, и мы работаем в двухуровневой установке, я понимаю, что между использованием STE и POCO не будет никакой разницы. Поскольку мы находимся в Интернете, и это автономная среда, в качестве альтернативы можно выбрать дополнительный SQL-запрос к Postback или необходимость присоединить сущность и изменить свойства по мере необходимости. Снова (поправьте меня, если я ошибаюсь) код будет выглядеть идентично.

Давайте рассмотрим простой пример, мы обрабатываем обратную передачу в приложении веб-формы: 

Person p = PersonManager.GetById(2); //we use the "requery" method
PersonManager.Update(p);

//If we dig into PersonManager.Update() we'll see the following:
PersonRepository.ApplyChanges(p); //we're assuming STEs are used so this API is available
PersonRepository.SaveChanges();

Предполагая, что позже нас попросят перевести архитектуру на трехуровневый, внедрив транспортный уровень WCF между Proj.Bussiness и Proj.Web, давайте назовем его Proj.Services. Если бы мы использовали STE для начала, разве мы не в лучшем положении? Все, что нам нужно сделать, это перенаправить вызовы на бизнес-уровень, без необходимости изменять его или репозитории любым способом: 

PersonService.Update(Person p)
{
    PersonManager.Update(p);
}

Если, например, мы использовали POCO (давайте предположим моментальный снимок), мы должны были бы кодировать таким образом, чтобы проверять, существует ли эта сущность в контексте (если мы запускаем 2-уровневый), и если не (3-х уровневый) прикрепите его и измените его свойства. Похоже, гораздо больше работы, когда вы не уверены, понадобится ли в будущем 3-уровневое решение. С другой стороны, если бы вы все время кодировали против STE, то единственный лишний (который на самом деле ничего не вредит) код, который вы бы вставили, - это вызов ApplyChanges (). В противном случае я не думаю, что вы что-то теряете (опять же, если ленивая загрузка не требуется). Что ты думаешь по этому поводу?

Ответы [ 2 ]

2 голосов
/ 19 июля 2011

STE не очень хорошо подходят для веб-приложений. Их проблема в том, как они работают:

  • Вы загружаете STE и закрываете контекст
  • Работа с данными, предоставленными в STE
  • Нажмите данные обратно к STE
  • Вы применяете изменения из STE к новому контексту, и он просто передает все изменения в графе объектов

Это кажется отличной особенностью, но, возможно, это не так. В случае ASP.NET это чаще всего означает:

  • Загрузка данных для начального поискового запроса и сохранение STE где-нибудь
  • Получить данные обратно в следующем запросе на обновление и заполнить данные обратно в сохраненную STE

Это ужасно, потому что требует, чтобы вы хранили STE либо в состоянии сеанса, либо в состоянии просмотра.

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

  • Первый раз, чтобы получить новый STE
  • Второй раз, чтобы передать обновленный STE обратно

Это не намного лучше, потому что у вас есть дополнительный удаленный вызов, который может передавать много данных (граф объектов) и после этого передавать весь граф объектов обратно.

Очевидно, что оба подхода нарушают некоторые архитектурные идеи

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

Они могут сделать удаленные сценарии намного проще, но они имеют свои собственные расходы (и они являются решением .NET-.NET ). Нет единой причины использовать их, если у вас нет удаленного сценария = Если вам не нужно использовать STE, просто не делайте этого . Более того, есть сообщения о некоторых проблемах с их реализацией. В голосе пользователя вы даже можете найти предположение, что они вообще не работают .

0 голосов
/ 07 августа 2011

Ладислав Мкнка высказал несколько отличных замечаний о том, почему НЕ стоит использовать STE, однако, похоже, что на этот вопрос не существует единого решения, подходящего для всех. Например, в моем текущем двухуровневом проекте они могут быть ненужными. Тем не менее, мы решительно надеемся использовать Silverlight для администрирования этого проекта в будущем. Это будет означать, что у меня есть один проект для модели и репозиториев, который, надеюсь, будет использоваться в обоих проектах более высокого уровня. Таким образом, один работает на 2-х уровнях, а другой - на 3-х уровнях (поскольку Silverlight требует служб). Насколько я могу судить, STE ведут себя точно так же, как POCO-снимки в «подключенной» среде, поэтому я не теряю / выигрываю много, используя их как таковые в двухуровневом приложении. Однако они, вероятно, окажутся очень полезными, когда мы добавим 3-х уровневую часть Silverlight. Надеюсь, что метод, описанный в моем первоначальном посте, хорошо подойдет для обоих типов приложений.

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

...