2013-02-23 9 views
11

Это может показаться глупым вопросом на поверхности, но почему Hot Towel SPA Template включает в себя Breeze?Почему HotTowel включает бриз?

Я провел последние несколько дней, изучая горячее полотенце и его зависимости, и насколько я могу судить, ничто в шаблоне не использует Breeze. Возможно, это изменится в будущем выпуске?

Конечно, бриз - хорошая библиотека. Но это связано с методологией CRUD и требует, чтобы вы разработали свой ApiControllers определенным образом. (Метаданные, SaveChanges и т. Д.) see here

Он также ведет вас к Entity Framework. Хотя это скорее мягкая зависимость, так как Breeze также показывает a sample without it, он по-прежнему ведет вас к аналогичной схеме реализации с использованием модифицированного шаблона репозитория.

Если вы используете хранилище данных NoSQL или шаблоны CQRS вместо CRUD, тогда Breeze становится очень сложным в использовании. Существуют альтернативные библиотеки для доступа к данным, которые хорошо работают в этом стиле, например AmplifyJS.

Но остальное горячее полотенце отлично! Мне особенно нравится Дюрандал. Поэтому возникает вопрос: если шаблон фактически не выполняет никакого доступа к данным - зачем вообще включать какой-либо компонент доступа к данным? Было бы лучше отправить его без Breeze, и если конечный пользователь захочет использовать Breeze или Amplify или что-то еще - тогда пусть будет так. Остальная часть Hot Towel будет продолжать светиться как отличная реализация SPA.

ответ

18

Matt - Хороший вопрос. Поскольку я создал его, я думаю, я должен ответить :)

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

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

Вернуться к шаблону Hot Towel ... если я включаю код, который использует Breeze, у меня возникнет соблазн добавить datacontext.js и model.js на клиенте. Они будут содержать код доступа к данным и код для расширения моделей на клиенте. Тогда у меня возникнет соблазн добавить контроллер, некоторые модели на стороне сервера, ORM и базу данных. Когда-то там я хотел бы использовать данные на нескольких экранах, что приводит меня к более нокауту и ​​кешированию с помощью Breeze. Тогда у меня может возникнуть соблазн добавить редактирование, что приведет к отслеживанию изменений. Вскоре у меня полнофункциональное приложение. Или более консервативно, у меня снова есть образец. Хотя эти подходы будут давать больше рекомендаций о том, как их объединить, они не помогут вам «начать» с шаблона, где вы можете просто начать создавать и добавлять свой собственный код. Если я прекращу некоторые из этих функций, он по-прежнему идет по дороге, которая требует от вас изменения, как я это сделал.

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

Вы можете поспорить (и вы можете быть), что Бриз не должен быть там, так как я не использую его в шаблоне. Я также не использую moment.js, BTW. Тем не менее, я утверждаю, что они оба отличные библиотеки, которые я бы не хотел создавать CRUD на основе SPA без них. Как вы полагаете, Бриз является гибким, поэтому вам не нужно идти по определенному пути.

Лучший способ понять значение Бриз - это создать приложение, имеющее свои функции, но без Breeze. Затем вы можете увидеть, сколько кода требуется и как это происходит. Для одного из таких примеров см. Мой курс SPA среднего уровня в Pluralsight, где я делаю именно это: http://jpapa.me/spaps

Итак, вы спрашиваете: «Почему Бриз?» ... потому что я настоятельно рекомендую его для строительства SPA.

Спасибо за просьбу и удачу!

+2

Как примечание стороны ... Усиление, в то время как фантастическое, не приближается к тому, что делает Бриз. –

+2

Спасибо за подробный ответ. Наверное, я использую Hot Towel больше как образец стартера, чем шаблон. Я вижу ваши точки. Для меня Бриз мешает, так как у меня уже есть богатый WebAPI для подключения. Для других, возможно, это лучше. Вы проделали отличную работу по подключению Durandal, а оболочка Hot Towel великолепно хрустящая. Мне было довольно легко заменить те части, которые мне не нужны, так что все хорошо. Серьезно, это спасло меня от неприятностей. Спасибо!!! –

+0

+1 Для включения moment.js. Отличная библиотека. –

7

Благодарим за вопрос.

Джон, как автор HT, предложил ответ. Я, как руководитель проекта Бриз, склонен согласиться с ним :)

HotTowel создает основу для вас. Это не само здание.

Это фонд, предназначенный для конкретного вида приложений, CRUD-приложения на основе определенного набора взаимодействующих технологий JavaScript и ASP.NET. Бриз - вкладчик ... но не единственный. Нокаут, с его MVVM-дизайном и двухсторонней привязкой данных, особенно хорошо подходит для задач ввода данных, типичных для приложений CRUD.

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

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

Верно, что легкий путь к Breeze проходит через веб-интерфейс API, EF и реляционную базу данных. Уберите их, и вы можете написать больше кода на сервере (и немного больше на клиенте). Это может быть идеальным компромиссом для вас.

Авторы Бриз хотели бы сделать этот путь проще. Я не думаю, что BreezeJS делает это сложнее. Я не понимаю вашего заявления «Бриз очень сложно использовать». Ты это пробовал?

Ваш клиент может взаимодействовать с любым HTTP-ресурсом любым выбранным вами способом. Достаточно просто использовать существующие контроллеры Web API (хотя и проще с контроллерами Breeze Web API). Вы можете использовать amplify.js, если хотите (кстати, вы можете сказать Бриз, чтобы делать AJAX-вызовы с усилением). Вам даже не нужно использовать Breeze EntityManager для запроса и сохранения данных, если вы этого не хотите.

Остальная часть BreezeJS может по-прежнему иметь ценность для вас. После того, как вы выяснили, как вы будете получать и хранить данные, и предпочитаете ли вы стиль Entity-ChangeSet или стиль Command/Query, остается много работы.

Вы должны найти ответы на эти вопросы:

  • Как вы будете формировать исходные данные в формате JSON в привязываемые объекты?
  • Как вы будете держаться за эти объекты и делиться ими на нескольких экранах, не делая избыточных круглых поездок на сервер?
  • Как вы будете перемещаться от одного объекта к связанному объекту так же, как и при привязке адреса к выписке StatesAndProvinces?
  • Как вы отслеживаете изменения?
  • Как вы их проверите?
  • Как вы будете хранить некоторые или все данные в локальном хранилище, когда приложение «надгробные плиты»?

Breeze может помочь с этими хлопотами, даже если вы не хотите, чтобы он запрашивал и сберегал вас.

И если вы ответ остается «Я сделаю все, что я, спасибо» ... ну, удаление Breeze с вашего HotTowel проекта так же просто, как:

Uninstall-Package breeze.webapi

+5

Мне очень хотелось бы увидеть привязку образца Breeze к некоторым существующим контроллерам веб-API ... возможно, Мэтт и Уорд могут взглянуть на это вместе. Было бы интересно увидеть результаты. –

+0

Спасибо за вашу точку зрения. Да, я пробовал ветер, и я согласен, что он имеет огромное значение для конкретных типов приложений. Клиентская библиотека отличная. Части, с которыми у меня возникают проблемы, находятся на стороне сервера. 'IQueryable' с OData велик, но' SaveChanges() 'и' MetaData() 'слишком проприетарны по моему вкусу. Я все еще пытаюсь [адаптировать образец NoDb для RavenDB] (https://breezejs.uservoice.com/forums/173093/suggestions/3233261), но он чувствует себя немного ограниченным на поверхности. Я надеюсь доказать себя не так. :) –

+6

Еще один момент: я хочу иметь возможность использовать одну и ту же конечную точку WebAPI как для создания собственного приложения, так и для предоставления моим клиентам SDK разработчика для подключения к моему внутреннему серверу. Мое приложение не должно иметь никакого специального доступа, и я не хочу заставлять других пользоваться бризом. Они могут быть на какой-то другой платформе целиком. Может быть, есть какая-то схема для согласования этого, о которой я не думал? –