3

私は現在、.Netの強く型付けされたデータセットを使用してDALを継承しているシステムで作業しています。私はこれまで彼らと一緒に仕事をしたことはありませんが、私はそれらを使用することに強い嫌悪感を持っていることに気づいています。POCOベースのDALと比較すると、それらは扱いにくく、管理が難しいように見え、結果として得られるオブジェクトは、データベース固有の懸念事項（たとえば、テーブルや行からのオブジェクトへのアクセス、キー値による目的のデータの取得など）と高度に結びついています。これをロジックレイヤーから抽象化するというDALの全体的な目的ではありませんか？）

データベース層の一部の書き換えやリファクタリングについては、いくつかの議論がありました。私は個人的に、これらのデータセットを削除したいと思っていますが、それらを使用することに慣れている同僚の何人かを説得するのに苦労しています。

強く型付けされたデータセットを使用することと、POCOベースのDALを使用することの長所と短所は何ですか？強く型付けされたデータセットを嫌うのは正当なことですか、それとも問題ではないというコミュニティのコンセンサスですか？私が見逃している他の解決策はありますか？

NHibernateのようなORMフレームワークを使用することには利点があることにも同意しますが、その複雑さのライブラリは私の同僚にとっては売れ行きが悪いと思います。誰かがこの方向に説得力のある十分な議論を提供することができれば、私はそれを聞きたいです。

4

1 に答える 1

2

強く型付けされたデータセットは、データベースアクセスへのデザイナーベースのアプローチを行う簡単な方法でした。それらはデータベースから生成でき、更新はかなり簡単です。また、データ型を適用できるという利点もあります。

これらは、DataSets、DataTables、DataAdaptersを備えた生のADO.NETとEntityFrameworkの間の移行段階と考えることができます。現在のメソッドの代わりに、デザイナーとデータベースの最初のコード生成を使用してEntityFrameworkを同僚に提示してみます。これはおなじみのパターンである必要があり、より簡単に移行できるようになります。また、既存のコードを改良するための追加作業の量を最小限に抑える必要があります。

その紹介を使用して、快適なレベルで作業し、後でPOCO、Linq、および新しいプロジェクトの関心の分離を紹介し始めることができます。通常、変更のペースが速いほど（および/またはワークロードが高いほど）、抵抗が大きくなることを忘れないでください。新しい方法論を一口サイズの断片で、そして安全な概念実証として提示できれば、はるかに好評を得ることができます。変化はリスクであるため、認識と未知数による潜在的な作業拡大の両方を管理することが重要です。

于 2012-07-03T21:05:49.797 に答える