11

これは一見馬鹿げた質問のように聞こえるかもしれませんが、なぜホットタオルSPAテンプレートにBreezeが含まれているのですか？

私はここ数日、ホットタオルとその依存関係を学習してきましたが、私が知る限り、テンプレートには実際にBreezeを使用しているものはありません。おそらくそれは将来のリリースで変わるのでしょうか？

確かに、Breezeは優れたライブラリです。ただし、これはCRUD手法にバインドされており、ApiControllerを特定の方法で設計する必要があります。（メタデータ、SaveChangesなど）ここを参照してください

また、EntityFrameworkについても説明します。これはよりソフトな依存関係ですが、Breezeはそれなしのサンプルも表示するため、変更されたリポジトリパターンを使用した同様の実装パターンをガイドします。

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

しかし、残りのホットタオルは素晴らしいです！私は特にデュランダルが好きです。したがって、テンプレートが実際にデータアクセスを行っていない場合、質問が発生します-なぜデータアクセスコンポーネントをまったく含めないのですか？Breezeなしで出荷する方が良いでしょう。エンドユーザーがBreezeやAmplifyなどを使用したい場合は、そうしてください。ホットタオルの残りの部分は、優れたSPA実装として輝き続けます。

4

2 に答える 2

18

マット-いい質問です。私はそれを作成したので、私は答えるべきだと思います:)

テンプレートを作成したとき、私は人々が適切なツールを使用できるようにするのに十分なものと、道を案内するのに十分なスターターコードを提供することに重点を置いていました。誰かがコードをリッピングしたくありませんでした。私は、あなたを道に導き、大量のファイルとコードを削除して方向を変えるテンプレートのファンではありません。これらはサンプルです。

サンプルは良いです。実際、サンプルは優れている可能性があります（他のテンプレートと同様に、サンプルに似ていると思います）。それらは別の目的を果たします：あなたが物事をどのように行うことができるかを示すこと。

ホットタオルテンプレートに戻る...Breezeを使用するコードを含めると、クライアントにdatacontext.jsとmodel.jsを追加したくなるでしょう。それらには、データアクセスコードとクライアント上のモデルを拡張するためのコードが含まれます。次に、コントローラー、いくつかのサーバー側モデル、ORM、およびデータベースを追加したくなるでしょう。そこに到達したら、複数の画面でデータを使用したいと思います。これにより、Breezeを使用したノックアウトとキャッシュが増えます。次に、編集を追加したくなるかもしれません。これは、変更の追跡につながります。すぐに本格的なアプリができました。またはもっと保守的に、私は再びサンプルを持っています。これらのアプローチは、これらを組み合わせる方法についてのより多くのガイダンスを提供しますが、独自のコードの作成と追加を開始できるテンプレートを「開始」するのには役立ちません。これらの機能のいくつかが足りない場合は、

現在のところ、HotTowelは本当の意味でテンプレートにかなり近いです。新しいプロジェクトを作成し、自分のコードを追加します。

私はテンプレートでBreezeを使用していないので、Breezeをそこに含めるべきではないと主張することができます（そしてあなたはそうかもしれません）。ところで、moment.jsも使用しません。ただし、どちらも優れたライブラリであり、それらなしでCRUDベースのSPAを構築したくないと私は主張します。あなたが示唆するように、Breezeは柔軟性があるので、特定の道を歩く必要はありません。

Breezeの価値を理解する最良の方法は、Breezeを使用せずに、その機能を備えたアプリを作成することです。次に、必要なコードの量とその複雑さを確認できます。そのような例の1つについては、Pluralsightの中間レベルのSPAコースを参照してください。ここでは、まさにこれを行っています：http: //jpapa.me/spaps

それであなたは「なぜそよ風？」と尋ねます ...SPAの構築に強くお勧めします。

質問してくれてありがとう！

于 2013-02-24T18:31:55.610 に答える
7

質問してくれてありがとう。

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

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

これは、特定の種類のアプリケーション、つまり、協力するJavaScriptおよびASP.NETテクノロジの特定のセットに基づくCRUDアプリケーションを対象とした基盤です。Breezeは貢献者です...しかし、それだけではありません。MVVM設計と双方向データバインディングを備えたKnockoutは、CRUDアプリに典型的なデータ入力タスクに特に適しています。

もちろん、他の種類のSPAもあります。ほとんどの場合情報を表示し、ユーザー入力をほとんど受け入れない重要なクラスのアプリがあります。このようなアプリはデータバインディングの恩恵をあまり受けず、それらを作成する人々は、データバインディング全般、特にKOについてかなり敵対的になる可能性があります。

私のポイントは、HTは特定のクラスのアプリケーションを対象としているということです...少なくとも持続的な人気で測定した場合、非常に成功しているアプリケーションです。それらのアプリを作成する人々に商品を届けます。他の種類のアプリの出発点としては適切ではない場合があります。

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

Breezeの作者​​は、その道をより簡単にしたいと思っています。BreezeJSがそれを難し​​くするとは思わない。「そよ風がとても使いづらくなる」というあなたの言葉がわかりません。試しましたか？

クライアントは、選択した方法で任意のHTTPリソースと通信できます。既存のWebAPIコントローラーを使用するのは非常に簡単です（Breeze Web APIコントローラーを使用すると簡単ですが）。必要に応じて、増幅.jsを使用できます（ところで、Breezeに増幅を使用してAJAX呼び出しを行うように指示できます）。必要がなければ、BreezeEntityManagerを使用してデータを照会および保存する必要はありません。

BreezeJSの残りの部分はまだあなたにとって価値があるかもしれません。データを取得して保存する方法と、Entity-ChangeSetスタイルとCommand / Queryスタイルのどちらを使用するかを理解した後は、まだやるべきことがたくさんあります。

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

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

Breezeは、クエリを実行して保存したくない場合でも、これらの雑用を支援できます。

そして、あなたが答えが「私はそれをすべて自分でやる、ありがとう」のままであるなら...まあ、あなたのHotTowelプロジェクトからBreezeを削除するのは次のように簡単です：

Uninstall-Package breeze.webapi

于 2013-02-24T20:24:01.980 に答える