1

私たちのソフトウェアは、ASP.NET と Oracle をデータベースとして使用するカスタマイズされた人事管理システム (HRMS) であり、現在、独自のデータベースを持つ複数のテナントをサポートする製品にするために実際に動いています。

私たちのオプション:

  1. NHibernate を使用して、複数のデータベースと OO の使用をサポートします。しかし、NHibernate の学習曲線と直面した問題に関連する懸念があります。

  2. ストアド プロシージャを使用して引き続き Oracle と連携する一般化された DAL を作成し、ツールを使用してそれを SQL Server や MySql などの他のデータベースに変換します。単一のスクリプトのデータベースに依存する複数のバージョンをサポートする必要があることに関連するリスクがあります。

  3. サービスとしてのソフトウェア (SaaS) を提供し、ビジネスの方法を維持します。ただし、クラウドやその他の SaaS ビジネス モデルを望まない、または信頼しないクライアントがいる可能性があります。

これを念頭に置いて、最良のデータ アクセス レイヤー手法は何ですか?

4

6 に答える 6

3

NHibernateは一見印象的で、学ぶのは非常に複雑に思えます。したがって、約260ページの紹介ドキュメントをすばやく読み、テストアプリケーション内で実行する必要のあるタスクを主張した後、NHibernateは実際に進むべき道です。また、XMLマッピングファイルに魅了されていない場合は、FluentNHibernateを使用するだけで、OOPを使用してビジネスドメインオブジェクトをマッピングできます。

さらに、NHibernateに完全に慣れておらず、別の方法を好む場合は、Enterprise Library 4.1（2008年10月）が便利なツールになる可能性があります。状況に応じて、一部の組織では、NHibernateとEnterpriseLibraryのハイブリッドアプローチを選択しました。エンタープライズライブラリ内のデータアクセスアプリケーションブロック（DAAB）は非常に簡単に習得でき、既に知っていること以外は何も習得する必要はありません。DatabaseProviderFactoryクラスからDbConnectionを作成して構成ファイルから読み取るために使用するオブジェクトを知る必要があるだけで、デフォルトのデータベースを指定できます。

私の懸念としては、NHibernateとEnterpriseLibraryの両方をよく使用します。DAABを使用すると、たとえば、ファイルごとに1つの接続のみをパラメーター化することを好むため、構成ファイルごとにデータベース接続を指定できます。これにより、まったく変更されていない構成の不必要な構成ファイルを展開せず、別の接続の新しい構成ファイルのみを展開できます。したがって、別のデータストアに接続する必要のある新しいモジュールをマージする場合は、残りの部分を気にせずにモジュールをビルドし、この新しいDAAB構成ファイルとともにモジュールのDLLでソフトウェアを更新します。

NHibernateに関しては、やらないことが重要なことは、ISessionFactoryが不要になったときにそれを取り除くことです。インスタンス化にはコストがかかるため、メモリに保持する必要があります。ただし、実行できるのは、構成オブジェクトクラスをシリアル化することです（Serializableであるため）。これにより、アプリケーションは、NHibernate構成ファイルに何かが変更された場合にのみ構成を構築できます。次に、NHibernateのデフォルトのhibernate.cfg.xml構成ファイルを使用することをお勧めします。これにより、更新が行われたときにapp.configファイルを何度もデプロイする必要がなくなります。

これがお役に立てば幸いです。さらに詳しい情報が必要な場合はお知らせください。

于 2010-01-29T14:25:07.247 に答える
3

時間をかけて、NHibernate を学習することをお勧めします。NHibernate には、データベースに依存しないデータベースのクエリと更新のための多くのオプションがあります。つまり、たとえば HQL で 1 セットのスクリプトを記述するだけで済みます。

Nhibernate by Example をお勧めします。これは、あなたを動かすための優れた本です。

于 2010-01-26T10:56:07.030 に答える
0

同様のシナリオ「HRM+ASP.NET +マルチDBサポート」があり、MyGenerationのdOOdadsアーキテクチャを選択しました。この製品はすでにリリースされており、かなりうまく機能しています。

MyGenerationをグーグルで検索すれば、準備は完了です。

SaaSについて：はい、多くのクライアントは、クラウド上にデータがどれほど安全であっても、そこにデータを置くことを受け入れません。市場で評判を得た後、これらのクライアントの一部を説得することができます。そのため、最初のフェーズでは、「社内展開」を優先度の高いものとしてサポートし、Saasを2番目の優先度としてサポートする設計に焦点を当てます。「社内展開」が選択肢にない場合は、SaaSマーケティングコンサルタントに相談することをお勧めします。

于 2010-01-26T10:51:02.643 に答える
0

私はオプション＃3を選択します。これにより、市場に最も早く参入でき、うまくいけば、堅調な収益源が生まれます。クライアントは、提案された製品よりも、既存の成功した製品をスタンドアロンシステムに変換するための資金をはるかに喜んで提供します。また、製品を改善する実際のユーザーから貴重なフィードバックを得ることができます。また、スタンドアロンシステムの需要がないことに気付くかもしれません。

ゼロから始める場合は、NHibernateを学ぶことをお勧めします。

于 2010-01-26T13:41:45.613 に答える
0

それはすべて優先順位に依存すると思います！

私の経験では、システムのどの部分も変更できるという事実を常に考慮しているため、少なくともシステムが他のデータベースとどのように連携してそれを進めるかを常に念頭に置いています。

明らかにあなたが最もよく知っていることを実行し、後でそうするための時間とお金があるときに適応/リファクタリングします。NHibernate / IOCを開発するときに、後のコンポーネントに導入してから、戻ってリファクタリングすることができます。

于 2010-01-28T13:21:53.253 に答える
0

複数のデータベース ベンダーをサポートする必要がある大規模なプロジェクト (テーブルが 20 を超える?) の場合、NHibernate を使用する方がカスタム ビルドの ORM よりも (開発コストと学習曲線の両方の観点から) 安価になることはほぼ確実です。リストの項目 3 への対応方法がわかりません。なぜなら、あなたが現在行っていることと NHibernate の使用を比較する方法がわからないからです。あなたが現在行っていることは実際には NHibernate よりも優れている可能性がありますが、その点に関して十分な情報を提供していません。技術的な決定に基づいて特定のビジネス モデルに固執することは、リスクの高いビジネス上の決定であり、後で元に戻すには費用がかかる可能性があります。

于 2010-01-26T13:32:47.357 に答える