1

私はついにMVC2の電車に乗ることに決めました。今、私は最近たくさんの読書をしていて、以下はほとんどのビジネスWebアプリケーションに十分だと思うアーキテクチャです。

階層化アーキテクチャ：-
モデル（データベースと通信する層）。EF4
リポジトリ（モデルと通信し、すべてのクエリを含むレイヤー）
ビジネスレイヤー（検証、ヘルパー関数、リポジトリへの呼び出し）
コントローラー（アプリケーションのフローを制御し、ビジネスレイヤーからビューにデータを提供する責任があります。）
ビュー（UI）

今、私はレイヤーごとに個別のプロジェクトを作成することにしました（関心の分離のジレンマを尊重するだけです。必要ではないことはわかっていますが、プロジェクトがよりプロフェッショナルに見えるようになると思います:-)

検証にAutoMetaDatat4テンプレートを使用しています。FluentValidationにも出くわしましたが、あまり見つかりません。どちらを使うべきですか？

どのビューエンジンを選択しますか？
RazorViewEngineは一目惚れでした。しかし、それはまだベータ版であり、その例を見つけるのは簡単ではないと思います。私は正しいですか？
スパーク..私もそれについて多くを見つけることができず、聞く人がいないときに助けを求めて泣きながら途中で立ち往生したくありません... :-(

T4テンプレートはビューを自動生成し、それらをカスタマイズしてビューを希望どおりに生成できますか？これはかみそりと火花で可能ですか、それとも手動で作成する必要がありますか？

リポジトリを自動生成する方法はありますか？

上記のアーキテクチャに基づいたプロジェクトを見ることができれば、本当にありがたいです。

従うのが良いアーキテクチャかどうか教えてください。
本当に必要なのか、というようなビジネスレイヤーの混乱があります。

4

4 に答える 4

0

これは非常に幅広い質問です。私はFluentNHibernateのautoconfig機能をグリーンフィールドアプリケーションに使用することに決め、非常に感銘を受けました。私の同僚の多くはCakePHPを使用しており、CakePHPが使用するデフォルトの規則と互換性のあるデータベーススキーマを生成するための構成はほとんど必要ありませんでした。これは私たちにとって素晴らしいことです。

于 2010-10-31T18:21:56.453 に答える
0

ASP.NET MVC2inActionという本を強くお勧めします。この本は、保守可能なASP.NETMVCアプリケーションの作成に使用されるライブラリのエコシステムをカバーするのに役立ちます。

ビューエンジンの選択に関しては、それはあなたのバックグラウンドに依存する可能性があります。個人的には、自分のビューをできるだけHTMLに近づけることを好むので、Sparkを選択します。一方、ASP.NETクラシックの操作に慣れている場合は、WebFormsビューエンジンを使用すると、起動と実行が最速になる可能性があります。

于 2010-10-31T18:23:29.417 に答える
0

コードからパターンを学ぶ方がはるかに簡単な場合があります。Sharp Architecture は、DDD を使用した MVC での優れたプラクティスの具体的な実装です。

于 2010-11-08T19:07:56.243 に答える
0

従うべき良いアーキテクチャかどうか教えてください。

それは素晴らしいスタートです-追加することをお勧めする唯一のものは、ビジネスロジックとデータアクセスの間の抽象化レイヤーです(つまり、依存関係の逆転/挿入)-これを参照してください:依存関係の逆転の紹介。

必要ないことはわかっていますが、プロジェクトがよりプロフェッショナルに見えるようになると思います:-)

ハ！通常、多くの「もの」は不要であることがわかります。必要になるまでは、通常は手遅れです。

ビュー エンジンについて: 私はまだ ASP.NET MVC の初心者なので、あなたが話しているビュー エンジンに慣れていません。もし私があなたなら、いくつかのテスト シナリオを思いつき、それから各製品でそれらに取り組み、それらを直接比較できるようにします。多くの場合、試乗をより快適にするために必要なものが必要です。これには時間がかかる場合がありますが、通常はそれだけの価値があります。

編集：

この層を首相に提案し、上記の 2 つの理由を彼に伝えた場合、彼はそれを受け入れないと思います

まず、PMは (通常は) テクニカル リードではありません。PM ではなく、ソリューションの設計に対する責任があります。これは珍しいことではありません。私の経験では、ほとんどの場合、首相はそこにないあなたの縄張りに侵入していることにさえ気づいていません。私が「政治的土地の略奪者」であるというわけではありませんが、「関心の分離」について考える傾向があるだけです。

設計者/アーキテクトとして、要件を解釈し、(ビジネスの優先順位を考慮して) 今後の最適な「プラットフォーム」を提供するソリューションを考え出すのはあなた次第です。

（DI について）私の質問は、本当に価値があるのか​​ということです。

もし私の頭に銃を向けられたら、私はイエスと答えるでしょうが、現実の世界はもう少し複雑です。

これらの質問のいずれかに「はい」と答えた場合、DI を使用する可能性が高くなります。

  • システムは自明ではありません
  • システムの予想寿命は 2 年以上です (ここに正しい数値が何であるかはわかりません。おそらく数値は存在しないため、この時点で地面に賭けることにします)。
  • システムおよび/またはその要件は流動的です。
  • 作業 (BL / DAL) を異なるチームに分割すると、プロジェクトにとって有利になります (おそらく、あなたは分散したチームの一員です)。
  • このシステムは、多様な技術環境を持つ市場を対象としています (例: 誰もが MS SQL を使いたがるわけではありません)。
  • 品質テストを実行したい (これにより簡単になります)。
  • システムが大規模/複雑であるため、機能を分割して他のシステムに配置する可能性があります。
  • データを保存する複数の方法を提供したいと考えています (無料のファイル ベースのリポジトリと、有料のデータベース駆動型リポジトリなど)。
  • ビジネスの原動力/環境は不安定です。彼らがあなたのところに来て、「これは素晴らしいが、今はクラウドベースのバージョンを提供したいのですが、Azure に載せることはできますか?」と言ったらどうしますか?

また、間違いなく学習曲線が関係していますが、それほど大きくはありません。速度に慣れれば、少なくとも現在と同じ速度を維持できることも指摘したいと思います。または最悪の場合、少し時間がかかりますが、より多くの価値を (比較的少ない労力で) 提供できます。

どれだけの労力がかかるかというと…

1 回限りのタスク (チームを最新の状態に保つことを超えて):

  • Provider Loader の作成または DI フレームワークの選択。これが完了すると、すべてのプロジェクトで再利用できるようになります。

「新しい」一般的なタスク (記事で取り上げたアプローチに従っていると仮定して):

  • インターフェースの定義 (紙の上) - これは、あなたが気付いていないかもしれないことを除いて、いずれにしてもあなたが今やっていることです。基本的には OO 設計ですが、2 つ以上のパッケージ間の正式なインターフェイスになるため、ある程度考える必要があります (もちろん、リファクタリングも可能です。ただし、理想的には、インターフェイスは「安定」してあまり変更しない必要があります。変更する場合は、既存のメンバーを「削除または変更」するよりも「追加」する方が適切です)。
  • インターフェースコードを書いています。実装を書いていないので、これは非常に高速です (数時間ではなく数分)。実装するときは、IDE が提供するツールを使用して、インターフェイスに基づいてコード スタブを生成できます。

今は別の方法で行うこと:

  • おそらくファクトリを介して、プロバイダーを保持するために (BL クラスで) 変数をインスタンス化します。これを書くのにそれほど時間はかからず (数時間ではなく数分で済みます)、必要に応じてコピー、貼り付け、リファクタリングするのはかなり簡単なコードです。
  • DAL コードの記述: 前と同じはずです。
于 2010-10-31T22:35:40.723 に答える