Разница между объектами Ember и данными Ember Data

Ответ 1

Примечание. Это довольно долго, предвзято и представляет мое собственное мнение по этому вопросу. Не может быть ответа.

Тип Object - это то, что вы могли бы назвать самым "простым" типом объекта в Ember. Он имеет наиболее важные функции, которые вы, вероятно, используете в современных приложениях, таких как вычисляемые свойства и наблюдаемые. И, связавшись с временем выполнения, он также позволяет связывание, фильтрацию и т.д. Я бы назвал его объектом общего назначения, который может быть расширен для создания других типов, также может быть объединен с mixins для дальнейшего повышения его использования. Он имеет большое, но ограниченное количество функций, но я бы не назвал его дружественным, только потому, что знаю DS.Model и его функции.

Ember-Data DS.Model значительно расширяет возможности в Object, чтобы предоставить больше возможностей, которые имеют смысл при работе с базовыми данными в (большинстве случаев) среде RESTful. Подобно объекту, поддерживаемому ORM (например:.NET EntityFramework или Ruby ActiveRecord), он предоставляет набор функций, поэтому объекты этого типа (DS.Model) могут управляться через хранилище данных (DS.Store) и помимо функций, уже присутствующих в Object, это позволит управлять состоянием (isDirty, isNew, isError, isNew и т.д.), возможность commit и rollback и объекта в хранилище (и впоследствии API-интерфейс), отношения/ассоциации и т.д.

Если вы используете Ember-Data вообще, вы должны использовать тип Model, так как он (предназначался для использования с хранилищем и) использует тип модели при загрузке, объединениях, множественных числах и на протяжении всего Рабочий процесс запроса/ответа AJAX. На самом деле одним из преимуществ использования Model, поддерживаемого a Store, является именно это: удержите фреймворк в тяжелом подъеме, построив запрос AJAX на правильный ресурс RESTful самостоятельно, управляя ответом, выполните боковое загрузку полезной нагрузки JSON в объект правильного типа, давая вам обещание использовать модель, пока данные запрашиваются/обрабатываются/материализуются (так что вы можете переходить к просмотрам/маршрутам, пока это происходит).

Он также дает вам множество удобных функций внутри самого объекта, поддерживаемого магазином (например: record.deleteRecord(); store.commit()), и в конце дня делает нас более продуктивными, и мы можем создавать приложения намного быстрее.

С учетом сказанного, есть критика такого подхода, потому что большое количество разработчиков обычно не любят или не чувствуют себя комфортно, прибегая к тому, что люди называют technomagic; другими словами, они не хотят использовать его, потому что считают, что они не на 100% контролируют то, что происходит под капотом. По моему личному мнению, в то же время я вижу, откуда эти люди, я считаю, что Ember-Data не помогает мне быть более продуктивным, и единственное, что он просит взамен, - это то, что я согласен с моим кодом и что я следую определенным соглашениям, и я доволен этим.

Вернемся к Object, если вы не используете Ember-Data, вы должны использовать тип Object в качестве своих моделей. Это означает, что вы будете выполнять все эти задачи вручную (как правило, не очень важно). Таким образом, вам придется вручную создавать запросы AJAX, обрабатывать ответ, загружать данные ответа в ваши объекты и в основном поддерживать весь рабочий процесс обмена между вашим клиентским приложением и вашим API. Преимущество состоит в том, что вы будете на 100% контролироваться, но с меньшими усилиями, как описано здесь Робин Уорд. Вы по-прежнему сможете использовать API маршрутизации и самые большие функции, которые делают Ember тем, чем он является.

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

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

• Является ли мой API возвратом JSON в том же формате, что и Соглашения об Ember?
• Если это правда только частично, может ли моя команда и я просто определить сопоставления на основе модели, чтобы все соответствовало соглашениям?
• Если нет, могу ли я изменить свой backend API для соответствия этим соглашениям?
• Если нет, где я могу найти адаптер, специфичный для моей бэкэнд-технологии?
• Я не могу найти его; было бы возможно написать собственный адаптер?

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

В конце дня вы должны понять, что эти объекты привносят с точки зрения возможностей и нужны ли вам они для создания вашего приложения. IMHO, Ember-Data - это путь для большинства случаев, и он может только улучшиться по мере приближения к (возможно, RC3, а затем) финалу Ember 1.0, который, вероятно, включит Ember-Data в качестве части пакета.

Надеюсь, это поможет