2009-05-14 5 views
6

モデルクラスのコードを生成するWPF/MVVMフレームワークを作成しています。WPF/MVVMアプリケーション用のデータレイヤフレームワークの特徴は何ですか?

  • 特異モデルクラス(例えば「顧客」)
  • :私は(例えば「顧客」)2つのモデルクラス各データベース・テーブル/ウェブサービスを持っていることを計画してい

    そして、複数のモデルクラス(例えば「顧客」)

特異モデルクラスありsingulaために理にかなっている、そのプロパティ(姓、姓など)に加えて、それのすべてのメソッドのすべて例えば、。

複数モデルクラスには、単一のオブジェクトのグループに対しても同じ方法を実行したいので、特異モデルオブジェクトのコレクションと同じメソッドがあります。例えばSave()、Delete()、CalculateSalary()だけでなく、Sort()などの特定のメソッドや、特定のグループ(例えば、などLoadAllGoldCustomers()、あるいはLoadWithSql(文字列のsql)、

私は(PHP)の前に、このようなフレームワークをやったし、それがこのようなコードを記述し、理解するためには非常に簡単に作られた:

Customers customers = new Customers("all"); 
customers.CalculateSalary(); 

カップル継承したクラス(項目や項目は、)でプログラムするための非常にクリーンな環境を作っている、各データベース・テーブルのための個々の単数形と複数のクラスのうち、コードのほとんどを取った。

しかし、私はめったに他の見ていませんアプリケーションはこれを行う単数/複数モデルクラス分割。代わりに、ほとんどの場合、それぞれのデータベーステーブルに対してただ1つのクラスが存在します。 Customerであり、このクラスには、必要な複数のメソッドがあります。

  • Customer.cs(フィールドのみ)
  • :GetCustomers(文字列のsql)など

    私はちょうどWPF Model-View-ViewModel Toolkit 0.1チュートリアルで気づいた、彼らはあなたが二つのモデル彼らの "モデル" ディレクトリ2つのクラスを作成してもらっては、同様の概念であるように思わCustomersDataSource.cs(1つの一覧ロード()メソッド)

は、「複数の」クラスは、データソースと呼ばれるだけのこと。

これで、WPF/MVVMに基づいた別のフレームワークを作成しようとしています。モデルクラスをどのように構造化するかを決めることができます。私は、フレームワークになりたい:

  • はっきりと単数または複数のクラスをインスタンス化して呼び出すためのViewModelから、単数形と複数形モデルクラスの鮮明な分離、あなただけが必要に対してプログラミングしやすいですあなたのデータがあります。
  • はMVVMパターンとうまくフィット(私はできる限りシンプルに保つための手段を理解し、ちょうどViewModelには、呼び出すことができるプロパティとメソッドを持っているが、そのようなINotifyProperityChangedなど何WPF固有の機能を実装しない)
  • がしたいの私のデータ層はのデータソースの上にあります。ですので、LINQ-to-SQLを使用しても私は自分のモデルクラスを呼び出していますが、Oracleでの保存に切り替えるには、それと相互作用する。可能

最善の方法でLINQの

  • テイク利点私は特にWPF/MVVM /コンポジットアプリケーションライブラリを使用してフレームワークのdatalayersを開発し、どのような特性あなたが最高の仕事を見つけた人たちからのフィードバックをいただければ幸いです、またはCSLA、Subsonicなどの他のフレームワークで作業している場合は、LINQの変更やデータレイヤー構造の構築方法に関する経験やアイデアもあります。ありがとう。

  • 答えて

    3

    ワウ。これは、座って話をすることなく、答えが難しい質問です。とにかくここでは短縮版になります。

    最初に、フレームワークまたはそのフレームワークの特性をある言語から別の言語に移植しようとすると、円形の穴に四角いペグを押し込もうとしているようです。機能(顧客や顧客など)を移植できるかどうかは疑いがありませんが、移植するべきではないと私は確信しています。 customer.CalculateSalaryの例では、.NETを使用して同じメソッドを実行したIEnumerableの拡張メソッドを作成し、Customersクラスの必要性を排除できます。あなたには他の機能もあるかもしれませんが、それは単なる例です。別の例では、LINQを使用してIEnumerableをソートしています。

    第2に、オブジェクトの内部で永続化メソッド(保存、削除など)を使用することは、特にWCFを扱う際に、大きなシステムではうまくいきません。これらのシナリオでは、後でいくつかのタイプのリポジトリを使用する方が良いと思われます。開発の途中でオラクルに切り替えるという点でもうまくいくようです。

    また、私はMVVMにうまく収まることについて、あなたに完全に同意したくありません。私にとって、ビューモデルは、モデルとビューの間の接着剤です。ビューモデルがビュー(したがって、WPF固有のフィーチャ)について知る必要があるだけでなく、そのビューモデルがそのことを知りたいと望む可能性があります。 ICommandは、WPF-yアセンブリ(WindowsBase、PresentationCore、PresentationFramework、どれが覚えていないか)を知るためのビューモデルにとって重要なインターフェイスです。また、INotifyPropertyChangedはデータバインディングにとっても重要であり、すべてのビューモデルで実装する必要があり、WPFとは関係ありません(System.ComponentModelから来ていますか?)。

    これは私の2セントです。繰り返しますが、あなたの質問への短い応答でこれを説明するのは本当に難しいです。私はそれのためのフレームワークを作る前にしばらくパターンを使用することをお勧めします。がんばろう!

    +0

    +1オブジェクトの内部で永続性メソッドがうまく機能せず、代わりにPI(永続性無知)PONO(普通の古いネットオブジェクト(POCO、普通の古いCLRオブジェクト))を使用できることを指摘しています。 – tobsen