簡単な質問がありますが、答えがかなり簡単であることを願っています。会社の共有従業員オブジェクト ライブラリを開発しようとしています。アイデアは、従業員に関する情報 (レポート階層、オフィスの場所、一般情報など) を含む集中データベースを作成し、このデータベースの共有オブジェクト ライブラリを作成することです。
私の質問は、このライブラリをアプリケーション間で共有できるように作成する最良の方法は何かということです。
質問は広く翻訳できるため、多くのオプションがあります。すべての答えを心に留めることをお勧めします。これが私のスピンだと言った...
私は以前、n 層のトレーニングのためにソフトウェア レイヤーを垂直と見なしていましたが、それらの概念から抜け出して、概念的により広範で制限の少ないものに移行するのに苦労していました。私は、.NET アセンブルを単なるパズルのピースと見なすよう努めています。
接続文字列をコードから分離するのは正しいことであり、それは .NET .config ファイルまたはアプリケーション設定によって簡単にサポートされます。
私はしばしば、ビジネス ロジック、概念、およびフローを含む小規模なコア ライブラリを好みますが、これらはそれぞれ分割することができます。そして、その概念の範囲内で、ビジネスをデータ アクセスから別のアセンブリとして分割し、新しい種類のデータ アクセスに交換することができます。ただし、コア モジュール (「ビジネス カーネル」または「エンジン」のようなもの) に固執します。
たとえば、多くのプレゼンテーション タイプを通じて「ビジネス カーネル」を表現できます。
パターンを使用してソフトウェアを思い通りに曲げたり、 Microsoft Enterprise Libraryなどの関連する実装を使用して開発を加速したり、 Ninject (多数のうちの 1 つ) や制御手法の反転などの依存性注入との結合を緩めたりすることができます。
私は通常、中間層レイヤー (つまり、クライアントとデータベース間の何らかの Web/WCF サービス) を使用することを好みます。このようにしてクライアントをデータベースから分離することで、接続数を制御したり、クライアントに対して透過的な方法でデータベースのスキーマを変更したりできます。
状況に応じて、クライアントを WCF サービスに接続させるか (ほとんどの場合に推奨)、サービスへの接続をラップしてクライアント側で追加の処理を実行する dll を作成することができます。
ライブラリをメインアプリケーションにどの程度深く統合する必要があるかによって異なります。カスタム エンティティを使用してアプリケーション ドメインを拡張する場合は、次のオプションがあります。
通常、ドメイン モデルを分離したアセンブリに配置すると、ほとんど問題が発生しません。
アプリケーションへの統合。通常、アプリケーション自体は、データ アクセス、セキュリティ、ロギング、Web サービスなどのサービスをほとんど提供しません。アプリケーションの設計が理想的で、レイヤーが互いに完全に分離されている場合、新しいエンティティを追加しても問題はありませんが、通常、データ アクセス レイヤーには からの継承が必要です。基本クラス、ロガーはシングルトン、セキュリティ チェックはビジネス ロジック メソッドなどにハードコードされています。そのようなアプリケーションはリファクタリングする必要があり、サービスはインターフェイスに抽出する必要があり、そのようなインターフェイスは別のアセンブリでコンポーネントに渡す必要があります。
エンティティ参照。リッチ ドメイン モデルを使用する場合は、別のアセンブリで宣言されたエンティティを参照する必要があります。この問題はジェネリックによって部分的に解決できますが、ジェネリック エンティティのリストを取得したり、id などでエンティティを取得したりできるように、データ アクセス レイヤーを特別に設計する必要があります。
データベースの統合。特に他のチームによって、一部のエンティティが他のエンティティとは別に開発されている場合、データベースの変更を維持するのは難しい場合があります。
接続方法をデータ アクセス レイヤーとは別にしておけば、後で要件が変わった場合に接続方法を変更できます。実際のロジックを保持する単純な DLL がある場合、その上に通信レイヤーを追加するのは簡単です。これにより、言及した3つの方法すべてを使用でき、実際のロジックをすべて3つすべてで使用される単一のDLLに含めることができます。