3

私は非常に大規模なデータ ベースのアプリケーションを開発する会社で働いています。このアプリケーションは約 10 年前に最初に作成されたため、アップグレードが切実に必要です。私は、データ層のアップグレードを調査して実装するタスクを与えられました。

現時点では、すべてがオブジェクトに基づいている/拡張されているビジネス オブジェクトを持つシステムを使用していDataRowます。つまり、各オブジェクトは多かれ少なかれデータベース内の 1 つの行に関連しています。アプリケーションは現在オブジェクト指向ではありませんが、これにより多くの問題が発生するため、OO 方向に移行したいと考えています。

そこで、.NET `Entity Framework' の使用を開始し、.edmx ファイルを作成することを検討しています。アイデアは、すべての SQL データベース テーブルを .edmx デザイナーにドラッグして、関連するデータ オブジェクトを作成させるだけです。

(OO 開発者としての) 私の考えでは、新しいビジネス オブジェクトを手動で作成し、新しいデータ レイヤーのクエリから返された .edmx 生成データ オブジェクトからデータを入力することを計画していました。これにより、インターフェイスを使用してさまざまなレイヤーを簡単に分離できます。

問題は、上司が、100 ほどのビジネス オブジェクト クラスを書き直すのに十分な時間がないと言い、.edmx で生成されたデータ オブジェクトをアプリケーション全体で使用することを提案していることです。

私の頭の中のすべての考えは「いいえ...データレイヤーとシステム全体の間にそのような結合を作成しないでください」と言いますが、上司はこれを促進するオンラインの記事を見たと言います。

皆さんへの質問は次のとおりです: (1 と 2 への回答の正当な理由を記入してください)

  1. これは実行可能な解決策ですか (短期的であっても)?

  2. 生成されたデータ オブジェクトから別のビジネス オブジェクトを作成するためのより良い/代替ソリューションはありますか?

  3. 手動でコピーして貼り付けるのではなく、生成されたデータ オブジェクトから別のビジネス オブジェクトを作成するためのより良い/簡単な方法はありますか?

これらの質問が主観的なものであることは承知していますが、できる限り具体的な情報を提供したので、この件に関してアドバイスをいただければ幸いです。

4

3 に答える 3

0

現在のアプリケーションの開発を開始したとき、巨大なedmxを作成しないように、CodeFirstを使用することにしました。彼らがそのデザイナーを改善している（分割するなど）と読んだのですが、100以上のオブジェクトを作成する必要があるため、edmxを試して使用したくありませんでした。

テーブルを読み取り、コード用のPOCOオブジェクトを作成する小さなアプリケーションを開発しました-最初に（これを行うためのツールがあると思います）、次にこれらすべてのオブジェクトのコンテキストcontaininigDbSetを表すクラスを作成します。

これらのオブジェクトをフロントエンドのMVCアプリケーションに直接使用しようとしたときに見つけたのは、循環参照の問題を伴うグリッドにオブジェクトを配置しようとすると、シリアル化の問題が発生したことです（jsonシリアル化の多用）。そこで、ViewModelを作成することにしました。速度が必要ない場合は、AutoMapperなどのツールを使用してテーブル<->ViewModelをマップします。速度が必要な場合（画面の一覧表示など）、結果をビューモデルオブジェクトに変換する実際のlinqクエリを作成しました。これに関して私が見つけた唯一の問題は、ビューモデルが非常にフラットでなければならないということです。

本当の答えではありませんが、これを経験した経験があります。

于 2011-10-27T11:08:24.643 に答える
0

問題は、上司が、100 ほどのビジネス オブジェクト クラスを書き直すのに十分な時間がないと言い、.edmx で生成されたデータ オブジェクトをアプリケーション全体で使用することを提案していることです。

  1. これは実行可能な解決策ですか (短期的であっても)? &
  2. 生成されたデータ オブジェクトから別のビジネス オブジェクトを作成するためのより良い/代替ソリューションはありますか? &
  3. 手動でコピーして貼り付けるのではなく、生成されたデータ オブジェクトから別のビジネス オブジェクトを作成するためのより良い/簡単な方法はありますか?

ANS: C# コードをリバース エンジニアリングして生成できるSybase PowerDesignerを試すことができます。または、 CodeSmith を試してコードを生成することもできます。これらのツールは時間を節約します。

Developer Express XPOやDataObjects.Netなどの他のフレームワークや、試すことができるLLBLGen Proもあります。

于 2011-10-27T11:49:37.467 に答える
0

これは、アップグレードしようとするすべてのレガシー システムで発生する一般的な問題の 1 つです。

「数百」のビジネス オブジェクトを作成し、EF データ オブジェクトから自分のデータ オブジェクトにデータをコピーする点がわかりません。まだ EF とビジネス オブジェクトを結合しています。

IoCデータ アクセス レイヤーからビジネス レイヤーへの分離を維持することを検討できる場合は、カップリングを使用して合格する必要があります。そして間違いなく、非常に少ないコスト/時間で ORM を切り替えることができます。これが の美しさですseparation of concern。

ソフトウェア業界では、今コストを削減したい場合、おそらく長期的にはより多くの費用を支払う必要があります (変更または ORM が再度必要になる場合)。

品質に関して上司と交渉してみてください。今は少しコストがかかるかもしれませんが、長期的には確実に得られます。

そしてあなたの場合、あなたは考えるかもしれませんEF Code First. これにより、データ アクセス レイヤーの設計を "データベース ファースト" よりも確実に把握できます。

また、ジェネレーターをコード化して、希望どおりにデータ アクセス レイヤーを生成することもできます。これにより、何百もの工数を節約できます。さらに、モジュールのより優れた実装を得ることができます。CodeSmith Generator を使用することをお勧めします。少し学習曲線がありますが、それだけの価値があります。

データ アクセスを分離することは、レガシー システムをアップグレードするための解決策ではないことに注意してください。私は、コア機能のアップグレードと保守が世界で最も困難な仕事になる多くのケースを見てきました。ビジネスマンが損失に直面したときに実際のアップグレードを決定しない限り、何もする必要はありません。

コア コンポーネントを特定してみてください。DAL はアップグレードする必要があります。

于 2011-10-27T11:24:36.213 に答える