問題タブ [separation-of-concerns]

ASP.NET MVC を読んでいると、ビジネス ルールがモデルに関連付けられていて、UI が一連のエラーを表示し、無効な入力に関連付けられたフォーム要素にフラグを立てるだけの検証の素晴らしい例に出くわしました。すべてのフォームに独自の検証を実行させるのではなく、このロジックを 1 か所に保持することは非常に理にかなっていると思います。

ASP.NET Web アプリケーション プロジェクト (Web フォーム) を使用して、この分離をエレガントな方法で実現することは可能ですか? 検証ルールをビジネス ロジック レイヤーに保持でき、検証を実行して一連のエラーを返すメソッドを使用できます。しかし、UI 側で問題のあるコントロールにフラグを付ける良い方法がわかりません。

MVC では、フォーム要素とモデルはプロパティ名によって暗黙的にリンクされます。ASP.NET の UI は、モデルの一意のプロパティ名を (ID/名前またはカスタム属性として) 参照する必要がありますか? コントロール名からプロパティ名への手動で生成されたマッピングに UI がアクセスできるようにする必要がありますか?

私が見たすべての例では、MVCがモデルとしてクラスを使用し、コントローラーとしてクラスを使用し、ビューとしてHTMLテンプレートを使用する必要があります。そして、それらはすべて、1つのindex.phpスクリプトと、サイト全体を実行するためのURL内のさまざまなリクエストで構成されていました。

だから、それらはすべて次のようなものでした...

モデルが単にデータを取得して保存するクラスで構成されている理由を理解しています（クラスは常に必要であり、関数を使用できると思いますが）。テンプレートが主にHTMLで構成されている理由を理解しています。しかし、なぜコントローラーがクラスなのかわかりません。コントローラーは手続き型スクリプト（モデルからユーザーデータを取得して表示用のテンプレートに送信するuserprofile.phpなど）であると想定します。

また、私が読んだすべてのチュートリアルでmodの書き換えが扱われ、「index.php？user = 1」やindex.php？news=3などのURLにリクエストがある単一のページを使用して全体を実行するのはなぜだろうと思っていました。サイト。user_profile.php？id = 1やnews.php？id =3..のような別々のページがあるのはどうしたのですか。

誰かが途中で簡単な「チュートリアル」と説明を手伝ってくれませんか。たとえば、MVCを使用して登録フォームをどのように実装するのでしょうか。ありがとうございました

PS。他にどのようなデザインパターンがありますか

私たちのアプリケーションには、何百ものプロパティを持つ多くのModelオブジェクトがあります。

モデルのすべてのプロパティについて:

ViewModelで INotifyPropertyChanged 対応のプロパティを作成する必要がありました。

これは、ビューがSaveイベントを送信したときに、ビュー モデルのこれらすべての値をモデルに再マッピングする必要があることを意味します。

モデルが変更され続け、すべての変更を ViewModel にマッピングする必要があったため、これは面倒で時間がかかりました。

しばらくして、View の DataContext をModel に直接接続する方が簡単であることに気付きました。これにより、XAML 要素を Model オブジェクトのプロパティに直接バインドできるようになり、save イベントでオブジェクトが何も指定されずに単純に保存されるようになります。マッピングは何でも。

この移動で失ったものは次のとおりです。

• UpdateSourceTrigger=PropertyChangedViewModel プロパティ セッターできめ細かな検証と操作を行う機能。これは非常に気に入りました。これは、XAML を変更するとモデルのダム プロパティが単純に変更されるため、もうありません。

• ビューモデルの UI ロジックを斬新な方法でテストするモック ビューを(将来的に) 作成する機能。 」、および（3）注文ボタンをより目立つようにします。

これらのアプローチにはどちらも明らかな利点があります。たとえば、最初の方法である「View-direct-to-Model」アプローチは、特にLINQ-to-SQLと組み合わせると実用的であり、有用なソフトウェアを迅速に作成できます{Binding...}。x:Name「ビューを Blend Designer に渡す」機能はまだあります。

一方、MVVM では Model から ViewModel への面倒なマッピングを維持する必要がありますが、最初のアプローチにはない強力な検証とテストの利点が得られます。

プロジェクトでこれら 2 つのアプローチの利点をどのように組み合わせることができましたか?

（Silverlightアプリの）viewModelがビューのUserControl.ResourcesXAMLセクションにあるいくつかの例を見てきました。Blendを使用するために、これはそれを持っているのに良い場所であることを読みました（Blendでサンプルデータを見る能力を与えるので）。

しかし、これはviewModelを持つのに最適な場所ですか？「ビューはサービスをviewModelにプッシュする必要がある」と読みました。これはどういう意味で、ViewModelを他にどこで作成できるか、または作成する必要がありますか？

ありがとう。JD。

私のドメイン クラスと永続化ロジック (Hibernate) は、model と呼ばれる 1 つのプロジェクトにあります。この jar は、すべてのアプリに含まれています。
パッケージ化された com.company.model & com.company.persistance

別の Utils.jar - DateTime、String、Thread などの一般的なヘルパー クラスが含まれています。これも私のすべてのアプリに含まれています。
パッケージ化された com.company.utils

データを操作するためのサービスを公開する CXF/Spring アプリがあります。CRUD 機能、その他すべての一般的な機能。これは、設計されたアプリのデータベースへの「方法」です。
com.company.services をパッケージ化し、Glassfish アプリ サーバーで実行

Web サービス (Spring 注入) を使用してデータを操作する他のアプリがあります。YUI ウィジェットと Web サービスからの XML/JSON を使用する Web アプリを含めて、優れたスムーズな UI を実現します。

私はそれが本当に質問ではないことを理解しています! これが他の人がソフトウェアを設計する方法であるという確認を探していると思います。私のアーキテクチャが適切で、論理的に理にかなっていれば! 明らかにセキュリティ上の懸念があります。サービス x へのアクセスのみを許可するアプリケーションが必要です。これらについては後で説明します。

ASP.Net MVC を使用した後、Rails について考えるようになりました。以前は Rails を使用していましたが、少しさびています。ASP.Net MVC チュートリアルでは、リポジトリ パターンを使用してデータ レイヤーの実装を非表示にすることを推奨しています。これにより、単体テストの依存性注入がより簡単になり、モデル実装からコントローラーを適切に切り離すことができます。

Active Record オブジェクトを直接使用する Rails のコントローラーと、簡単にセットアップおよび破棄できるテスト データベースを使用した単体テストを覚えています。これにより、ユニット テストのためにスワップ アウトする必要がなくなりますが、それでも、あまりにも多くの ActiveRecord コードをコントローラーで公開するのは良くない考えのように思えます。

私の質問は、ここでの最新のベストプラクティスは何ですか? 実際の (モックではない) データベースはまだ単体テストに使用されていますか? Rails 開発者は ActiveRecord を直接呼び出しますか、それとも抽象化しますか?

問題：

特定のスタイル（一部のOO、関数ライブラリ、一部のテンプレート、テンプレートなし）で コーディングされたレガシーphpアプリがあり、ゆっくりと書き直し、クリーンアップし、追加しています。

私がシステムにテンプレートを導入したとき、それが与えるhtmlとphpの分離のために、それがコードを本当にクリーンアップして単純化することはすぐに明らかでした。私は自分の仕事でphpMVCフレームワークを使用してきましたが、MVCの概念を具体化する関心の分離が本当に好きです。ただし、大規模なコードベースがもたらす複雑さは気に入らない。私はシンプルさが大好きで、本当に複雑なスタックが登場すると、無限にネストされたデバッグをうまく処理できません。時が経つにつれて、主にClojureの調査により、私はますます機能的なスタイルのファンになりました。

php 5.3以降に移行するときに、phpのより機能的なスタイルに移行したいので、最適にはオブジェクト指向コードをあまり使用せず、スタックも多く使用せずに、phpの懸念を分離する良い方法が必要です。

ソリューションのフレーミング：

• 大きな/複雑なオブジェクトはありません。
• デバッグ用の短いスタック。
• php 5.2を実行すると、debianでリリースされるまで5.3にアップグレードできないため、機能的なスタイルがあればいいのですが、5.3のツールはしばらく利用できない可能性があります。
• 現在フラクチャされているコードベースを統合するためのクリーンでシンプルなテーマ。
• 現在のコードへの影響が少ないほど良いです。

単一責任の原則と関心の分離の違いは何ですか？

mvc の調査を始めたばかりで、まだ理解できていません。私が収集したものから、3層ソリューションの実装のように見えます。つまり、モデルはDALに対応し、コントローラーはビジネスロジックレイヤーに対応し、ビューはプレゼンテーションレイヤーとして表示されます。

私はここで基地から離れていますか？

私は自分のコントローラーをテストし、関心の分離を維持しようとしています。

最初の懸念は、「誰がどのアクションを実行できるか」です。認証にauthlogicを使用
し、承認にbe9のacl9を使用しています。しかし、これは重要ではありません。私の承認に関する懸念はすべて、で処理されます。私はこれに似た何かによってそのようなものをテストしています：before_filterbefore_filter

この仕様は問題なく機能しています。

さて、2番目の懸念は「アクションはそれがすることになっていることをするのか？」です。
これには、承認の確認は含まれません。最良/最もクリーンな解決策は、それをすべて一緒にスキップしてbefore_filter、次のようなことを行うことです。

どのロールのどのユーザーが最初にログインする必要があるかを心配する必要はありません。今、私はそれをそのように解決しました：

私のsiteadminがインデックスアクションにアクセスする権利をもう持っていないと判断した場合、1つの仕様、つまりそのような場合に破る必要のある仕様だけでなく、まったく関係のない2番目の仕様も破ることになります。

これは基本的に小さな問題ですが、誰かが（エレガントな）解決策を思い付くことができれば素晴らしいと思います！