DTO = ViewModel?

Мы можем использовать DTO то же как Образцовый класс, и мы можем использовать viewmodel, когда мы должны показывать/использовать данные/свойство многоуровневых моделей в единственном представлении. Пример: Я создаю некоторую модель с помощью базы данных платформы объекта сначала. Так, теперь вся модель генерирует на основе базы данных. и теперь нам нужно аннотирование данных, для тех аннотирование данных мы можем создать DTO имени папки В этой папке DTO, мы можем сохранить все модели точными, которые уже генерируют и добавляют аннотирование данных выше свойства. Тогда мы можем использовать любую операцию (используйте контроллер, представления), использующий этот DTO классы. И когда нам нужно сложное представление, я имею в виду, когда нам нужны несколько данных классов в одном представлении там, мы можем использовать viewmodel. Для viewmodel мы можем создать имя папки viewmodel, затем создать пользовательский класс и сохранить то свойство, в котором мы нуждаемся. Я пытался очистить меня. Любое предложение высоко ценится.

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

Обычно DTO используются для передачи данных с одного уровня на другой через границы процессов, так как вызовы к удаленному сервису могут быть дорогими, поэтому все необходимые данные заталкиваются в DTO и передаются клиенту одним фрагментом (крупнозернистым).

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

http://blog.jpboodhoo.com/CommentView,guid,21fe23e7-e42c-48d8-8871-86e65bcc9a50.aspx

В простых случаях, как уже было сказано, эта DTO может быть использована для привязки к виду, но в более сложных случаях это потребует создания ViewModel и выгрузки данных из DTO в ViewModel, что, очевидно, более трудоемко (при применении MVVM-шаблона).

Итак, опять же, как уже говорилось DTO!=ViewModel

и

DTO и ViewModel имеют разные цели в жизни

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

Для меня это баланс между быстротой (используя DTO, так как они у меня уже есть) и гибкостью (создание ViewModels означает больше разделения проблем)

Может показаться не таким вычурным, но я настоятельно рекомендую JavaScript.

Много лет назад я был силен в разработке PHP, но затем переключился на Java, C #, C, Objective-C. За время работы на Java я глубоко вошел в JavaScript и сделал несколько довольно классных вещей с ним. Кто-то, кого я знаю, разработал целую клиентскую временную облегченную СУБД. Просто посмотрите на Ext.js, что они делают с JavaScript. Это так недооценено, но не заслуживает этого. Я предлагаю тебе погуглить для «Видео Дугласа Крокфорда.» На Yahoo он создал несколько отличных презентаций о JavaScript, также я предлагаю вам получить книгу «Javascript - The Good Parts» от Дугласа Крокфорда, и «JavaScript - The Definitive Guide». Обе лучшие книги JavaScript доступны. И вы будете поражены, что возможно и какой красивый язык на самом деле. На самом деле, вы можете сделать ИИ с ним, у него есть Лямбда, на самом деле нет ничего «круче», чем это! Какая жалость она используется только для написания сценариев на клиентской стороне. Мало кто знает, что JavaScript также может использоваться для программирования на стороне сервера, но это действительно редкость/не очень хорошо задокументировано.

Благодаря Adobe Air на рабочий стол можно вывести JavaScript.

Это было бы оптимальным дополнением к вашим знаниям PHP. Всегда хорошо делать связанные вещи. Вы можете быть лучшим веб-разработчиком или лучшим архитектором настольного программного обеспечения. Но наш мозг слишком медленный, чтобы понять всю профессию, необходимую сегодня, чтобы быть Гуру во многих направлениях. Я думаю, что бить гуру необходимо для успеха. Некоторые мои друзья просто делают одно: пожирают гуру. Они изучают всю свою жизнь по одному маленькому предмету и чрезвычайно успешны. Они зарабатывают в 5 раз больше, чем любой я-могу-сделать-все-но-знать-только-5 %-в-этой теме-Разработчик только за четверть времени.

Поэтому я также предлагаю: напишите 600 страницы PHP книги , прежде чем вы забудете свои PHP знания, делая что-то совершенно другое.

Я забыл почти все, что знал о PHP и JavaScript, но в те первые дни я определенно был одним из ребят-экспертов, которые показали другим много всего. Теперь это боль, что я должен снова спросить так много основ, чтобы вспомнить их в моем крошечном мозге. Написав свою книгу, вы будете очень быстро вспоминать свой опыт PHP даже после нескольких лет работы с чем-то другим, потому что это ваша книга, подходящая вашему мозгу, от вашего мозга. И вы не потеряете свой PHP-экспертный статус даже после нескольких лет работы.

Удачи.

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

Еще одна вещь, которую разработчики должны понимать, состоит в том, что при разработке базы данных следует иметь в виду три вещи:

1. Целостность данных - если данные не могут быть основаны на вас, по существу, нет данных -это означает, что не следует вводить требуемую логику в приложение, поскольку многие другие источники могут касаться базы данных. Ограничения, внешние ключи и иногда триггеры необходимы для целостности данных. Не забудьте использовать их, потому что они вам не нравятся или вы не хотите, чтобы их поняли.

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

3. Безопасность - эти данные являются кровью жизни вашей компании, они также часто содержат личную информацию, которая может быть украдена. Научитесь защищать свои данные от атак с помощью SQL, мошенничества и кражи личных данных.

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

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

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

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

Если у вас нет администратора базы данных, убедитесь, что кто-то создает резервные копии, знает, как их восстановить, и протестировал их восстановление.

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

DTO! = ViewModel

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