8

さて、ここに社内にユーティリティがあり、データベースのテーブルとビューからビジネスモデルクラスを生成します。これは、ORMに似ています（ただし、まったく同じではありません）。それを維持する際に、スキーマ内のデータが大幅に変更される可能性は低いと思いました。ただし、機能は可能性があります。今後、機能を追加したいと思うかもしれません。その機能の一部を生成したい場合や、拡張したい場合があります。

構築しているクラスは、他のライブラリやアプリケーションで使用できるようにクラスライブラリに常駐します。そこには大きな驚きはありません。しかし、ここでの難点は、クラスを再生成するときにコードをできるだけ中断しないように、生成されたクラスを設計する方法です。たとえば、コードがプロパティ（データベーステーブルの列を表す）に追加されている場合、それを失いたくありません。

したがって、頭に浮かぶ2つのアプローチがあります。

古典的な継承。すべてが単一の「モノリシック」クラスで行われ、コンシューマーは基本実装を自由にオーバーライドできます。ただし、これは時々トリッキーになり、キャストの頭痛の種になることがよくあります。さらに、派生クラスが注意を怠り、基本クラスの機能を呼び出すのを忘れると、問題がすぐに発生する可能性があります。

部分クラス。このスキームでは、ビジネスオブジェクトを個別の部分（プロパティ（列にマップされる）と動作）に分割します。ビヘイビアーは、生成されたビヘイビアーとカスタムビヘイビアーにさらに分類することもできます。ご覧のとおり、このアプローチの問題は、その固有の複雑さです。さらに、命名の問題があります。

これが皆さんへの私の質問です：あなたがこのようなシナリオを扱っているとき（もしあれば）、またはあなたがこのようなシナリオを提示された場合、あなたはどのような解決策を考えますか、そしてその理由は何ですか？

4

5 に答える 5

13

パーシャルクラスが.Netに含まれている理由は、コード生成ツールを簡単に利用できるようにするためです。

コードを生成する場合は、部分クラスを使用します。とても簡単です。将来的にコードを再生成する必要があり、カスタマイズでコードを再更新するために大量の作業を行う必要があるというリスクを冒すのはなぜですか？

パーシャルもそれほど複雑ではないと思います。これは、複数のファイルに分割された1つのクラスにすぎません。一方のファイルに生成されたコード、もう一方のファイルにカスタムコード。

于 2009-06-26T18:01:52.510 に答える
4

私は部分的なクラスのパスに行きます。1つのオブジェクトを多くの部分に分割するのにより自然にフィットするからです。Linq2Sqlでさえパーシャルを使用します。パターンと適切な慣習で複雑さと戦ってください。また、部分クラスで「部分更新」（生成されたコードが適切に構造化されている場合）を実行する方が簡単です。

コードを生成していない場合は、クラスの継承方法を使用してください（実際には、強制され、パーシャルが異なるアセンブリ間で機能しなくなります）。

于 2009-06-26T18:01:08.423 に答える
3

これはまさに、解決するために部分的なクラスが存在する問題です。とはいえ、実用的な目的には少し行き過ぎかもしれません。アプリケーションの詳細を知らない私の直感的な反応は、クラスの生成されたすべてのコードに部分的なクラスファイルを使用し、手動で作成されたすべてのコードに2番目のファイルを使用することです。生成された部分クラスの命名規則を考え出し、それを守ります。

于 2009-06-26T18:01:32.417 に答える
0

（xmlに）シリアル化される型があり、いくつかの機能を追加したい場合は、継承ではなく部分クラスを使用する必要があります。ありがとう///M

于 2010-08-12T12:42:33.993 に答える
0

あなたは言う：

ORMに似ています（ただし、まったく同じではありません）

現在のソリューションの保守コストに関する予測値をいくつか作成し（これは重要だと思います）、ORMを選択し、概念実証ソリューションを作成して、それを維持するための比較数値を作成します。このカスタムパッケージのメンテナンス、立ち上げ、開発者の賛同にかかる費用はわかりませんが、私はこのような「カスタム」製品の近くには行かないでしょう。知識は移転できず、エラーのリスクが高く（常にコード生成の場合）、基盤となるデータベースの内部に拘束されます。

于 2012-07-02T23:45:06.640 に答える