Breeze.js смешивает DTO и юридические лица

В статье Уорда " The Breeze Server: имей свой путь ":

  

Типичное бизнес-приложение имеет модель домена минимум 200   типы. 90 +% времени форма данных, которые я отправляю по   провод такой же, как форма объекта в моей бизнес-модели.
  ...
  Когда форма объекта клиента не совпадает с формой   бизнес-объект на стороне сервера, я могу переключиться на DTO для этого   частный случай.

Это очень важно для нашего приложения, но как лучше всего переключить некоторые сущности для DTO?

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

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

Есть ли способ изменить сущность пользователя для пользовательского DTO повсюду в модели? Для всех других объектов в модели, которые ссылаются на пользователей, нам все еще нужно иметь возможность загружать их с расширенными пользовательскими свойствами, запрашивать их по этим пользовательским свойствам и сохранять их с изменениями этих пользовательских свойств.

Я не уверен, как это сделать, кроме как создать большую модель DTO, которая на 95% идентична модели сущностей, и иметь некоторый код /​​структуру сопоставления для перехода между ними. Но, как говорит Уорд в этот пост ," мне не нравятся DTO для каждого типа; это излишне, что может снизить производительность. "

4 голоса | спросил Joe Daley 28 MarpmFri, 28 Mar 2014 14:49:03 +04002014-03-28T14:49:03+04:0002 2014, 14:49:03

1 ответ


0

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

Вскоре (если вы являетесь разработчиком .NET), вы можете найти некоторые подсказки в примере DocCode. Поиск "ProductDto". DocCode не показывает, как вы можете сохранить изменения, поэтому мне придется отложить это до другого раза.

Ваш сценарий действительно может быть легко решен.

Шаг № 1: Используйте пользовательский DbContext

Начните с написания подкласса DbContext вашей бизнес-модели. Добавьте к этому подклассу переопределение к вашему OnModelCreating и научите его игнорировать User свойства, которые не должны быть частью модели.

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
   modelBuilder.Entity<User>().Ignore(u => u.whatever);
   ...
   base.OnModelCreating(modelBuilder);
}

Теперь обращайтесь к ЭТОМУ производному DbContext при общении с клиентами.

Обратите внимание, что это включает в себя очень небольшой объем кода и прост в обслуживании. Это не мешает вам использовать базовую DbContext, которая сохраняет полный доступ ко всем свойствам User

Шаг № 2. Настройте JSON.NET для исключения этих свойств из сериализации

Следуйте Руководство Джеймса Ньютона Кинга . Посмотрите, в частности, на IContractResolver, если вы не хотите украшать /загрязнять свой User класс с атрибутом [JsonIgnore]. Джеймс является автором JSON.NET.

ответил Ward 28 MarpmFri, 28 Mar 2014 22:06:08 +04002014-03-28T22:06:08+04:0010 2014, 22:06:08

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132