1

これがシナリオです。csla 3.8 / c#.net を使用してアプリケーションを開発しています。アプリケーションにはさまざまなモジュールがあります。ERPのようなもので、会計、日々の勤怠記録、採用などをモジュールとして持っています。

ここでの要件は、モジュールごとに共通のエンティティをチェックし、そこから「プラットフォーム」を構築することです (<- ボスはそのように呼んでいます)。たとえば、DTR にはエンティティ「employee」があり、Recruitment には「Applicant」があるため、プラットフォームに配置できる両方から派生できる 1 つの共通エンティティは「Person」です。「人」には、名前、住所、連絡先情報などの一般的な情報が含まれます。

私はそれが OOP 101 のように聞こえることを知っています。単純な継承であればいいのですが、要件は、CSLA を使用してモジュールで使用される何らかの API を作成することです。

csla では、businessListbase、readonlylistbase などの csla の基本クラスから継承して、スマート オブジェクトを正しく作成します。たとえば、ビジネスベースの応募者クラスを作成した場合、給与要求、利用可能日などのプロパティが含まれます。個人情報については、「プラットフォーム」から「人」が必要になり、それを応募者クラスに実装します。

要約すると、いくつか質問があります。

  1. そのようなプラットフォームを作成する方法は?
  2. そのようなプラットフォームが可能である場合、各モジュールのエンティティにどのように実装されますか? （私はすでにcslaの基本クラスから継承しています）
  3. ケース1とケース2が可能である場合、アプリの開発やメンテナンスにメリットはありますか?

#3 を質問している理由は、そのためのプラットフォームを作成できたとしても、モジュール エンティティでプラットフォーム エンティティのプロパティを定義して、検証とすべてを行う必要があるためです。 .

4

2 に答える 2

1

基本クラスからの継承については正しいです。

  1. リレーションシップを含めずに基本エンティティを設計することから始めます。次に、新しく作成したエンティティから継承するクラスを作成し、親エンティティから (FK 関係を介して) データベースから取得する子プロパティを追加します。また、 CSLA 3.8.2 テンプレートもチェックすることをお勧めします。それらは VB.NET と C# の両方のフレーバーで提供され、このタスクをより簡単にします。
  2. はい、可能性があります。#1 で概説した手順に従ってください。
  3. メリットもデメリットもわかりませんが、今後のメンテナンスもしやすいと思います。派生クラスは、基本クラスの上にルールを追加したり、基本クラスのルールを完全に制御したりできます。

ありがとう -Blake Niemyjski ( CodeSmith CSLA テンプレートの作成者)

于 2010-03-22T11:07:05.887 に答える
0

「プラットフォーム」エンティティまたは現在ジェネリック BO と呼んでいるものの主な目的は、コードの再利用です。そのため、会計や購買などの将来モジュールを追加すると、これらのジェネリック モジュールを自由に使用できます。

最終的に、私の解決策は、複数のモジュールで使用されるオブジェクトを決定し、それを別のプロジェクトに分離して、他のモジュールがオブジェクトを必要とするときにそのプロジェクトを使用するようにすることでした。

私の最初の例では、応募者 (募集用)、従業員 (毎日の時間記録)、および人 (「プラットフォーム」) です。何が起こったかというと、Person が一般的な BO プロジェクトに配置されました。申請者と従業員の両方が、個人 BO を子プロパティとして使用するだけです。

返信ありがとうブレイク。ところで、これには実際に codesmith を使用しています。まだ提案をありがとう。乾杯！

于 2010-08-05T09:43:54.827 に答える