8

私は職場で次の質問に出くわしました.私はそれらに答えるための経験や知識がありません.賢明な人々の何人かが私を正しい方向に向けることができることを願っています.大歓迎です!

シナリオ

個別のデータベースを使用するビジネスの 2 つの側面、人事と業務領域 (ホームケア) があります。
人事部門は、会社の従業員、シフトパターン、欠勤、給与などを追跡します。ホームケアは、クライアント情報、家庭訪問、訪問日、およびその訪問を担当する従業員を追跡します。

これら 2 つのシステムは別個のものであり、現在、それらを統合する方法を検討中です。

さらに、これら 2 つのデータベースを参照するコードを、再利用可能で整理されたライブラリに整理する方法を検討しています。

ライブラリに含まれる EF 4 オブジェクト コンテキストとの通信を担当する HumanResources.dll を再利用する 3 つのアプリケーションがあります。オブジェクト コンテキストは、現状のデータベースのほぼ鏡像です。

質問

HR データベースのデータを使用する 4 つ目のアプリケーションを追加しようとしています。

私たちは：

従業員などの一般的なエンティティを複製しながら、アプリケーションのみが必要とする情報を提供する新しい EF データ モデルを作成します。

また

新しいエンティティ/テーブルを既に大きなモデルに追加し、モデルが大きくなることを受け入れます。

長期的には、5 番目のアプリケーションで、人事データベースのシフト パターン情報を、業務エリア (ホームケア) データベースのクライアント訪問に結合する必要があります。

何ができるかについてのアイデアがあります。私たちは次のことを考え出しました：

HumanResources オブジェクト コンテキストと Homecare オブジェクト コンテキストの間に位置するレイヤーを作成し、2 つのデータ セットを結合します。

私たちに利益をもたらす他のアプローチはありますか？

4

4 に答える 4

12

ファサード パターンを実装する

ファサードは基本的に、複雑なサブシステムのアダプターです。2 つのサブシステムがあるため、次の機能を持つ 3 つのクラスを作成することをお勧めします。

  1. HumanResourcesFacade: すべての「人事」機能をラップするクラス。このクラスの役割は、人事アプリケーションに関する情報をクライアントに公開することなく、人事アプリケーションが担当する各作業単位を実行するメソッドを公開することです。

  2. HomecareFacade: すべての「在宅ケア」機能をラップするクラス。このクラスの役割は、Homecare データベースに関する情報をクライアントに公開することなく、Homecare アプリケーションが担当する各作業単位を実行するメソッドを公開することです。

  3. ApplicationFacadeHumanResourcesFacade:およびとの両方をラップするクラスでHomecareFacade、ネストされた 2 つのファサードの内部動作の知識を必要としないパブリック メソッドをクライアントに提供します。このクラスの仕事は、(a) 2 つのネストされたファサードのどちらが各クライアント呼び出しを担当するかを知ることです。(b) ネストされたファサードで適切なメソッドを呼び出すことによって、ApplicationFacade のクライアントの呼び出しを実行し、( c) ネストされたファサードから受信したデータを、クライアントが使用でき、ネストされたファサードのデータ形式に依存しない形式に変換する。

POCO オブジェクト モデルを使用して、実際の永続化の実装に依存しない共通のコード内表現を作成することをお勧めします。Adrian K が提案したドメイン モデル手法は優れたアプローチですが、パターンと方法論に慣れていないと、より直感的な手法よりも非常に混乱し、時間がかかる可能性があります。別の方法は、データ オブジェクトとData Mapperを使用することです。データ マッパーは、基本的にデータ ソースからデータを取得し、データ ソースまたはマッパー オブジェクトに依存しないオブジェクトに変換します。以下のリンクを含めました。

明確にしたいことの 1 つは、 には 3 つのジョブがあると言いましたが、単一責任の原則ApplicationFacadeに違反することを勧めているわけではないということです。クラスがこれら 3 つのことすべてを単独で実行する必要があるという意味ではありませんが、そのプロセスを実行するために使用することを決定したメカニズムをカプセル化する必要があり、アプリケーションの他の部分が. たとえば、ビジネス オブジェクトは、どのデータ ソースから構築されたかを認識してはなりません。その情報は、クラスによってカプセル化されたもの以外からアクセスできないようにする必要があります。ApplicationFacadeApplicationFacade

参考記事

于 2011-03-05T16:41:52.877 に答える
2

本格的なデータモデリングを行う必要があるようです。

深刻な争いに巻き込まれないように、長期的には間違いなく必要です。(システムをサポート/拡張し、ビジネスの成長をサポートする能力に大きな影響を与えるものがあるとすれば、それはデータ管理です)。(ビジネス) データの良い点は、ビジネス関係者がデータを十分に理解している (またはそうすべきである) ことと、適切な動機でサポートすることです。そのような演習がもたらす価値は、簡単に売り込めるはずです。短期的にこれらのいくつかを実施することも役立ちます。

パッケージ製品 (Commercial Off The Shelf - COTS) に付属するデータ ソースは、それらのシステムを危険にさらすことなく変更することはできません。データを一緒に。この種のアプローチでは、データ モデリングとシステム間のデータ マッピングが重要になりますが、タイミングも重要です。

社内アプリの方が柔軟性がありますが、非常にやむを得ない理由がない限り、戦術的な変更には抵抗した方がよいかもしれません。

この演習の一環として、各データの記録システムについて検討する必要があります。データはどこから来るのでしょうか? 誰がそれを所有していますか？概念的なデータ モデルを作成することで、高レベルから始めることができます。これはおそらく、特定の「列」よりも論理的なデータセットを扱うことになります。

この情報を使用して、さらなる決定を導きます。

あなたの当面のアプローチ（およびあなたの質問）に関して：一般的に言えば、システムとデータの間に抽象化のレイヤーを配置することを考えて、それが起こったときにアプリケーションが変化から緩衝されるようにします。

従業員などの一般的なエンティティを複製しながら、アプリケーションのみが必要とする情報を提供する新しい EF データ モデルを作成します。

複製の大きな問題は、データを泥だらけの状態にすることです。これが「実際の」記録です。これは簡単にあなたを殺すことができます。あなたのコンテキストでこのアプローチの利点は何ですか? サポータビリティの観点からこれを行いますか? 開発のしやすさ？

于 2011-02-24T12:20:30.423 に答える
1

それは、統合の意味に大きく依存します。

  • レポート目的でさまざまなテーブルを組み合わせたいだけの場合は、各システムから選択したデータを抽出してデータウェアハウスにロードするプロセスを検討する必要があります。両方のシステムに共通のデータ モデルを定義する必要があります。このデータは、レポート用に使用できます。
  • あるシステムでサービスを呼び出したり、別のシステムからデータを取得したりしたい場合は、従来の SOA パターンを使用することをお勧めします。他のシステムで利用できるようにする機能を、SOAP、REST メッセージなどを介してサービスとして公開します。また、クライアント システムでこれらのメソッドを使用し、これらのメソッドのみを使用してデータを送信または取得するようにします。

外部システム データベースを直接調べたり、あるシステムから別のシステムにデータを複製したり、ソース システムに直接 API 呼び出しを行ったりすることは、可能な限り避けてください。指針となる原則は、「システム X をシステム SuperX に置き換えると、他のシステムを機能させ続けることがいかに簡単になるか」です。

于 2011-06-15T05:17:04.387 に答える
0

長期的なソリューションを探していて、それはビジネスのインフラストラクチャに関するものなので、LDAPに移行することをお勧めします。読んでください。

于 2011-06-16T07:35:22.557 に答える