Усиливает ли Breeze потребность в DTO в одностраничных приложениях?

Question

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

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

Answer 1

Есть причины для DTO. «Сглаживание данных» - не один из них. Ни один из них не ограничивает количество данных, которые я вкладываю в провод.

Breeze отлично справляется с графами объектов. Представьте, что вы отправляете 100 заказов для клиента. Вы не хотели бы повторять имя клиента в каждом заказе DTO. С Breeze вы запрашиваете заказы клиента (используйте «expand»), и вы получаете одну копию Клиента и заказы, чтобы пойти с ним.

 
var query = new breeze.EntityQuery.from('Customers') 
      .where('Id', 'eq', 42) 
      .expand('orders'); 

С другой стороны, если вы хотите только список имен клиентов, используйте «проекцию»:

 
var query = new breeze.EntityQuery.from('Customers') // all customers 
      .select('id, companyName'); // project into an anonymous 2-property object 

Используйте случайный стороне сервера DTO, чтобы построить что-то, что вы не можете легко создавать с клиента (например, клиент-и-общий-текущий-год-доллар).

Дело в том, что вы можете смешивать запросы DTO, проекции и объекты в соответствии с вашими потребностями. Вам не нужно идти так или иначе (по-моему).

Answer 2

В настоящее время мы оцениваем изменение с Нокаутом на Угловое и Бриз, чтобы избавиться от большей части кода DTO и DTO-Mapping, который мы написали (код сервера и клиента). Мы сделали это, чтобы не подвергать DAO, а создавать DTO для всех объектов. В конце концов, что произошло, мы имели во многих случаях (не все) классы, которые выглядели на 90% похожими на объекты базы данных. Это привело нас к заключению, что DTO в нашем случае не имеют смысла, и накладные расходы, которые мы взяли, были потрачены впустую, и нам нужно избавиться от этого с лучшим подходом. Таким образом, должен начаться этап рефакторинга :-)

Так как в одном месте у нас есть два эксперта (@John и @Ward), я бы также рискнул ответить на этот вопрос и, кроме того, поднял вопрос о реализации, который я до сих пор не полностью ответил за себя, и, возможно, Джон и Уорд могут это прояснить, поскольку я считаю важным важным аспектом вопроса, если DTO все еще необходимы.

Взяв на ветер, кажется, очень помогает избежать большого количества кода DTO и DTO-Mapping, и я полностью согласен с тем, что использование DTO для получения меньше по проводам вместе с бризом не имеет смысла, потому что это что-то который отлично обрабатывается ветром, как описано выше, с запросом на стороне клиента. Это то, что я могу полностью подтвердить и иметь смысл. Кроме того, создание многих различных классов DTO, как мы это делали, - не лучший подход. Бриз делает это намного лучше с гораздо меньшим количеством кода.

Чтобы использовать код отображения DTO и DTO для разделения проблем, я по-прежнему считаю, что это хорошая идея и принцип, но в нем также много накладных расходов, что, вероятно, во многих случаях не требуется. Поэтому, чтобы воспользоваться бризом, вы можете, конечно, создавать DTO и писать/генерировать метаданные на стороне клиента, но это не основная идея бриза. Вы можете использовать его таким образом, но чем больше вы остаетесь на DAO, тем меньше кода вам придется писать и быстрее ваш проект. Но тем не менее бриз позволяет вам это, так что каркас также будет работать с DTO, его просто не основная идея, почему был написан бриз. Лучшим подходом является сочетание обоих (воздействие DAO и DTO).

Но когда использовать DTO?

• безопасности
• Комплексная логика (расчет) или когда вы не можете использовать простые методы CRUD, потому что слишком большого количества сложности, которые вы не будете или не может (безопасность) выставит на стороне клиента.

В случае безопасности я на самом деле не уверен на 100%, и именно поэтому я пишу здесь и хотел бы попросить двух экспертов. Мы используем EF на стороне сервера, и, вероятно, лучшая идея - использовать прогнозы на стороне сервера для обеспечения безопасности. Но как это сделать?

Я поднимаю этот вопрос, потому что я считаю его самым важным ответом на то, что он может ответить на вопрос, нужны ли DTO.

Мы закончили со следующим кодом для EF (в нашей оценке демо):

private IQueryable<News> RestrictFields(IQueryable<News> query) 
    { 
     return query 
      .ToList() // This seemd to be needed, otherwhise I cannot use new News() 
      .Select(t => new News() 
       { 
        Id = t.Id, 
        Text = t.Text, 
        Title = t.Title, 
        Date = t.Date 
       }) 
      .AsQueryable(); 
    } 

Так как вы можете видеть выше, у нас есть запрос EF. Итак, первое, что мы пробовали, было просто для проекции с новыми новостями(). Это не сработало, поскольку EF не позволяет использовать один и тот же класс DAO в проекции, только объекты DTO или анонимные. Поэтому мы использовали обходной путь ToList(), а затем AsQueryable(). Но это не кажется правильным, и, возможно, тогда параметры запроса от клиента не будут отправлены в базу данных и, вероятно, некоторые из них не будут работать из-за этого, например, «expand».

Так что лучший способ сделать проекцию на стороне сервера по соображениям безопасности, чтобы окончательно избавиться от необходимости в DTO? @John: Я видел сообщение о вас, где вы говорите, вы использовали прогнозы на Speakers в своем демо-проекте для своего учебного класса (Angular and Breeze), но я не нашел, где это реализовано.

Здесь я действительно застрял, и это для меня недостающее звено, чтобы узнать, нужны ли DTO или нет, и как он тогда может отлично работать вместе с Бриз.

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

С наилучшими пожеланиями,

Chris