11

満足のいく答えを見つけられた気がしない、または適切な場所を探していないという質問があります。

私たちのシステムはもともと .NET 1.1 を使用して構築されました (ただし、現在はすべてのプロジェクトが 3.5 をサポートしています)。すべてのエンティティは、ストアド プロシージャと、標準の ExecuteReader、ExecutreNonQuery タイプ メソッドを持つ「SQLHelper」を使用してデータベースに永続化されます。

したがって、一般的に発生するのは、たとえば User と Role などのエンティティがあり、次のようなメソッドを使用してこれらのオブジェクトをデータベースに永続化する UserIO という別のクラスがあることです。

 static UserIO.SaveUser(User user)

別の IO ファイルの理由は、IO をエンティティから分離しておくためですが、呼び出すだけの方が満足できるのではないでしょうか?:

User.Save()

たぶん私が間違っているかもしれませんが、これらの「IO」ファイルがあちこちに散らばっているのは正しくないと感じています。そのため、永続化のための他のオプションを検討することを考えており、どこから始めるのが最適なのか疑問に思いました。過去にデータセットを使用したことがありますが、特にそのパフォーマンスに関して、いくつかの複雑な経験がありました。LINQ が存在することは知っていますが、LINQ ではなく ADO.NET Entity Framework を使用する必要があると聞きましたが、Entity Framework は正しくないため、C# 4.0 を待つ必要があると他の人から言われました。その場合、C# 4.0 がもうすぐリリースされるので、"IO" ファイル アプローチを続けて、C# 4.0 が最終的にリリースされたときに Entity Framework から始めるべきです。または、部分クラスを利用するなど、使用できるよりエレガントなクラス構造はおそらくありますか?

私は、既存のデータ アクセスを完全に置き換えることを検討しているわけではありません。私が作成している新しいエンティティに関心があります。

この質問が少し一般的である場合は申し訳ありませんが、この種の考えを跳ね返す人はあまりいません。

4

5 に答える 5

4

Entity Framework 3.5 を正常に使用できました。Entity Framework が一連の規則に違反しており、使用すべきではないと感じている純粋主義者と見なす人もいます。

私の意見では、重要な唯一のルールはあなた自身のものです。Entity Framework 3.5 を使用して実験を開始することをお勧めします。また、できるだけ早く、あなた (および他のほぼ全員) が .NET 4.0 の実験を開始する必要があります。Release Candidate は無料で入手できるので、少なくとも何が入手可能かを知らない理由はありません。

4.0 での EF の変更が気に入って、それを待ちたくなる可能性があります。待つ必要がなく、3.5 の場合と同じように EF の恩恵を受けることができます。待っていなくてよかったです。

于 2010-03-04T18:53:35.357 に答える
3

オブジェクト リレーショナル マッピング モデルを探している場合は、以下を調べることができます。

ここにも長いリストがあります: http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#.NET

永続化のためのオブジェクト モデルの設計方法に関する一般的な質問に関しては、設計の選択の多くは、システムの複雑さ、必要な拡張性、複数の永続ストア (SQLServer、Oracle、ファイル システムなど) をサポートする必要があるかどうかによって異なります。 )、 等々。あなたが説明するパターンはDataTansferObject (DTO)のように見えます。ビジネス ロジックから永続化ロジックを分離するための一般的な設計です。

余談ですが、優れたシステム設計の一般原則は、単一責任の原則です。システムを構築するときは、さまざまな責任を 1 つのクラスにまとめることが理にかなっているかどうかを判断する必要があります。責任を結合すると、多くの場合、システムが複雑になり、解決が困難な設計上の競合が発生する可能性があります。

于 2010-03-04T18:48:45.997 に答える
2

私がかなり定期的に使用するパターンは次のとおりです。各オブジェクトには次のものがあります。

  • データ転送オブジェクト (DTO) - データセットが使用するメモリを可能な限り小さく保ちます。
  • ビジネス オブジェクト - 少なくとも上記の DTO をコンストラクターとして使用します - これは、CRUD 関数ではない DTO で任意の関数を実行します
  • CRUD / Repository クラスの永続メソッド

後者は、2 つの方法のいずれかで実行できます。いくつかのオブジェクトしかないアプリケーション/コンポーネントに適した大きなリポジトリ クラスを作成することも、オブジェクトごとに個別のリポジトリを作成することもできます。

Rudy Lacovaras のブログをご覧ください。彼は最近、同様のパターンを使用した効率的なデータ アクセスに関する一連の投稿を行いました。

于 2010-03-04T19:24:32.483 に答える
0

データ関数を実装する一連のクラスを持つことは、階層型プログラミングと呼ばれることがよくあります。( http://en.wikipedia.org/wiki/N-tier )。データ層にアクセスするクラスを分離することで、より保守しやすいシステムを作成できます。これらの関数をアプリケーションのビジネス ルールを実装するクラスにマージすると、多層設計の利点の多くが失われます。

データ アクセス関数を独自のクラスに分割するのは良いことですが (設計者に 3 拍手)、あちこちに分散させるのは良くありません。これらの関数のソースをすべて同じディレクトリまたはファイルに配置しないことが理想的です (プロジェクトのサイズによって異なります)。それらがすべて揃っている場合、多くの利点が得られます。それらを(ランダムに?)多くの場所に分割すると、このコードをモジュール化する目的が無効になります。

于 2010-03-04T18:55:37.000 に答える
0

モデルとは別のリポジトリを持つのはよくあるパターンです。IO という名前は、このようなパターンでは一意ですが、有効です。誰と話しているかによっては (TDD ナッツが頭に浮かびます)、静的クラスを使用することで失敗する可能性があります。

于 2010-03-04T18:47:50.570 に答える