2013-02-23 5 views
11

これは表面上のばかげた質問のように聞こえるかもしれませんが、なぜHot Towel SPA TemplateにはBreezeが含まれていますか?HotTowelにBreezeが含まれているのはなぜですか?

私はホットタオルとその依存関係を学習し、最後の数日間過ごしてきた、と私の知る限り、テンプレートには何も実際ブリーズを使用しません。おそらくそれは将来のリリースで変わるだろうか?

確かに、Breezeは良いライブラリです。しかし、CRUDの方法論に縛られており、ApiControllersを特別な方法で設計する必要があります。 (などのメタデータ、SaveChangesメソッドは、)see here

また、Entity Frameworkのにあなたをガイドします。これはソフト依存関係にありますが、Breezeもa sample without itと表示されるため、変更されたリポジトリパターンを使用して同様の実装パターンを導きます。

あなたがのNoSQLデータストア、またはCQRSパターンの代わりに、CRUDを使用している場合は、ブリーズは使用することは非常に困難になります。 AmplifyJSなど、このスタイルでうまく機能するデータアクセス用の代替ライブラリがあります。

しかし、残りのホットタオルは優れています!私は特にDurandalが好きです。したがって、テンプレートが実際にデータアクセスを行っていない場合、なぜデータアクセスコンポーネントが含まれているのでしょうか? Breezeを使用せずに出荷する方が良いでしょう。また、エンドユーザーがBreezeやAmplifyなどを使用したい場合は、そうしてください。ホットタオルの残りの部分は、偉大なSPAの実装として輝いていきます。

答えて

18

マット - よくある質問です。私はそれを作成したので、私は答える必要がありますね:)

私は道を導くために、私は適切なツールと一緒に行く人々を得るために十分な提供にフォーカスを持っていたテンプレート、およびだけで十分なスターターコードを構築しました。私は誰もコードを抽出したくなかった。私はパスを始めるテンプレートのファンではなく、たくさんのファイルとコードを削除して方向を変えるようにします。それらはサンプルです。

サンプルが良好です。実際、サンプルは優れている可能性があります(他のテンプレートのように、サンプルに近い感じです)。それらは別の目的を果たします:あなたが物事をどうやってできるかを示すこと。私はブリーズを使用するコードが含まれている場合

戻るホットタオルテンプレートに...、私はdatacontext.jsとクライアント上model.jsを追加するために誘惑されるだろう。これらは、クライアント上でモデルを拡張するためのデータアクセスコードとコードを含みます。次に、コントローラ、いくつかのサーバーサイドモデル、ORM、およびデータベースを追加したいと思うでしょう。そこにいたら、私は複数の画面でデータを使いたいと思うので、Breezeを使ってノックアウトとキャッシングに繋がります。それから、編集を追加したくなるかもしれませんが、これは変更の追跡につながります。まもなく私は完全な吹き飛ばされたアプリを持っている。または、より保守的に、私は再びサンプルを持っています。これらのアプローチは、これらの方法を組み合わせる方法についてより多くのガイダンスを提供しますが、独自のコードを作成して追加するだけのテンプレートを使用して「開始」することはできません。これらの機能のいくつかが足りなくなっても、私はそれをやり直す必要がある道を歩いています。

今日のように、HotTowelは真実の意味でのテンプレートにかなり近いです。新しいプロジェクトを作成し、オフにして独自のコードを追加します。

私はテンプレートでそれを使用していないので、ブリーズはそこにあるべきではないとあなたは主張することができ(そして、あなたは可能性があります)。また、私はmoment.js、BTWを使用しません。しかし、私はそれらがCRUDベースのSPAを構築したくない優れたライブラリであると主張します。 Breezeは柔軟性がありますので、特定の道を歩く必要はありません。

Breezeの価値を理解する最善の方法は、Breezeを使用せずに機能を備えたアプリケーションを構築することです。それで、どのくらいのコードが必要か、それがどの程度関与しているかが分かります。そのような例については、Pluralsightの私の中間レベルのSPAコースを参照してください。http://jpapa.me/spaps

なぜ「なぜBreezeですか?」 SPAの構築に強くお勧めします。

お問い合わせありがとうございます!

+2

サイドノート... Amplifyは素晴らしいですが、Breezeの機能に近づくことはありません。 –

+2

詳細な回答ありがとうございます。私はテンプレートよりもサンプルスターターのようなホットタオルを使用していると思います。私はあなたのポイントを参照してください。私にとっては、既に豊富なWebAPIを持っているので、Breezeがやり遂げられます。他の人にとってはおそらくそれが良いでしょう。あなたはDurandalを結ぶ上で素晴らしい仕事をしたし、Hot Towelのシェルはすばらしく鮮明です。私が望まない部分を交換するのはかなり簡単だったので、それはすべて良いことです。真剣に - それは私に多くのトラブルを救った。ありがとうございました!!! –

+0

+1 moment.jsを含めてください。優れたライブラリ。 –

7

ありがとうございます。

ジョンは、HTの著者として、答えを提供しています。私は、Breezeプロジェクトのプリンシパルとして、彼に同意する傾向があります:)

HotTowelは、あなたが構築するための基盤を生成します。建物そのものではありません。

特定の種類のアプリケーション、協力するJavaScriptとASP.NETテクノロジの特定のセットに基づくCRUDアプリケーション用の基盤です。 Breezeは貢献者ですが、唯一の人ではありません。 MVVM設計と双方向データバインディングを備えたノックアウトは、CRUDアプリに典型的なデータ入力タスクに特に適しています。

もちろん、他の種類のSPAがあります。主に情報を提示し、ユーザーの入力をほとんど受けない重要な種類のアプリがあります。そのようなアプリは、データバインディングの恩恵をそれほど享受しません。そのようなアプリは、一般的なデータバインディングや特にKOについてかなり敵対的になります。

私の指摘は、HTは特定のクラスのアプリケーションをターゲットにしているということです。少なくとも持続的な人気によって測定された場合、非常に成功しています。それらのアプリケーションを構築する人々のための商品を提供します。それは他の種類のアプリのための適切な開始場所ではないかもしれません。

Breezeへの簡単な道は、Web API、EF、およびリレーショナルデータベースを介して実行されることは事実です。それらを取り除くと、サーバー上にコードを書くことができます(クライアント上ではもう少しです)。それはあなたにとって完璧なトレードオフかもしれません。

Breezeの作成者は、そのパスを簡単にしたいと考えています。 BreezeJSが難しくなるとは思わない。私はあなたの声明を理解していません "Breezeは非常に難しくなります。"あなたはそれを試しましたか?

クライアントは、任意の方法でHTTPリソースと通信できます。既存のWeb APIコントローラーを使用するのは簡単です(Breeze Web APIコントローラーでは簡単ですが)。必要に応じてamplify.jsを使用できます(btw、増幅でAJAX呼び出しを行うようにBreezeに指示できます)。あなたがしたくない場合は、Breeze EntityManagerを使ってデータを照会して保存する必要はありません。

残りのBreezeJSは引き続き価値があります。データを取得して保存する方法と、Entity-ChangeSetスタイルまたはCommand/Queryスタイルを好むかどうかを理解した後に、たくさんの作業が残っています。

あなたはこれらの質問に対する答えを見つける必要があります:

  • どのようにバインド可能オブジェクトに生のJSONデータを形作っていきますか?
  • これらのオブジェクトを保持し、サーバーへの冗長な往復をせずに複数の画面でそれらを共有するにはどうすればよいですか?
  • StatesAndProvincesのコンボボックスにアドレスをバインドするときと同じように、オブジェクトから関連オブジェクトにどのようにナビゲートしますか?
  • 変更をどのように追跡しますか?
  • どのように検証しますか?
  • アプリを「墓石」にすると、ローカルストレージにデータの一部または全部をどのように保存しますか?

Breezeは、これらの雑用をクエリして保存したくない場合でも役立ちます。

そして、あなたが答えている場合だけでなく、あなたのHotTowelプロジェクトからブリーズを除去することと同じくらい簡単です...「あなたをありがとう、私はそれをすべて自分自身をやる」のまま:

Uninstall-Package breeze.webapi

+5

既存のWeb APIコントローラにBreezeサンプルのネクタイを見たいと思っています。おそらく、MattとWardが一緒にそのことを見ることができます。その結果を見るのは面白いだろう。 –

+0

あなたの視点に感謝します。はい - 私は風を試しましたが、特定のタイプのアプリケーションには大きな価値があると私は同意します。クライアントライブラリは素晴らしいです。問題がある部分はすべてサーバー側にあります。 ODataを使った 'IQueryable'は素晴らしいですが、' SaveChanges() 'と' MetaData() 'は私の好みのためにあまりにも独占的です。私はまだ[RavenDBのNoDbサンプルを適合させる](https://breezejs.uservoice.com/forums/173093/suggestions/3233261)を試みようとしていますが、表面上は少し制限されていると感じています。私は自分自身が間違っていることを証明したい。 :) –

+6

もう1つのポイント - 自分のアプリケーションをビルドし、バックエンドサーバーに接続するための開発者SDKを提供するために、同じWebAPIエンドポイントを使用できるようにしたい。私のアプリは特別なアクセス権を持ってはいけません。私は他人に風を使わせたくありません。彼らは完全に別のプラットフォームにいるかもしれません。多分私は考えていないこれを調整するためのパターンがありますか? –