独自のデータアクセス/データマッピングレイヤーの作成は「良い」アイデアですか？

現在、すぐに使用できるオブジェクトリレーショナルマッパーを使用するか、独自のロールを作成するかを選択できる状況にあります。

残念ながら、データ層とビジネス層が一緒にマッシュされたレガシーアプリケーション（ASP.NET + SQL Server）があります。システムは、データアクセスに関して特に複雑ではありません。相互に関連するテーブルの大規模グループ（35〜40）からデータを読み取り、メモリ内で操作し、サマリー形式で他のテーブルに保存します。現在、いくつかのリファクタリングの機会があり、データアクセスを分離して適切に構造化するために使用する候補技術を検討しています。

どんなテクノロジーを選択したとしても、

• ドメインモデルに、持続性に無知なPOCOオブジェクトがある
• モックアップされた基礎となるデータソースに対してドメインモデルオブジェクトをユニットテストできるようにする抽象化レイヤーがあります

パターンとフレームワークなどに関しては、明らかにこれに関するものがたくさんあります。

個人的には、EFをADO.NET Unit Testable Repository Generator / POCO Entity Generatorと組み合わせて使用​​することを推進しています。これはすべての要件を満たし、Repo / UnitOfWorkパターン内に簡単にバンドルでき、DB構造は適度に成熟（既にリファクタリング済み）であるため、モデルに毎日変更を加えることはありません。

ただし、グループの他のメンバーは、独自のDALを完全にゼロから設計/ローリングすることを提案しています。（カスタムDataMappers、DataContexts、リポジトリ、どこでもインターフェイス、具体的なオブジェクトを作成するための依存性注入過剰、カスタムLINQから基になるクエリ変換、カスタムキャッシングの実装、カスタムFetchPlanの実装...）狂気として私。

投げかけられた議論のいくつかは、「少なくとも、私たち自身のコードを制御できるようになる」または「以前のプロジェクトでL2S / EFを使用したことがあり、頭痛に過ぎなかった」です。（私は以前に実稼働環境で使用したことがありますが、問題はごくわずかであり、非常に管理しやすいものでした）

だから、あなたの超経験豊富な開発者/アーキテクトには、この製品を完全な災害になると思われるものから遠ざけるのに役立つかもしれない知恵の言葉があります。EFの問題をかわすことで得られる利益は、車輪の再発明を試みることで、すぐに失われると思います。

既存のORMに対する両方の引数は無効です。

「まあ、少なくとも私たちは自分のコードを管理するでしょう」

自分の言語を書いてみませんか？あなた自身のフレームワーク？あなた自身のオペレーティングシステム？また、すべてを確実に制御できるように、独自のハードウェアを作成することもお勧めします。

「ああ、以前のプロジェクトでL2S / EFを使用したことがありますが、それは頭痛の種に過ぎませんでした」

EFは十分に成熟しており、多くの人が正常に使用しました。EFは頭痛に過ぎないと主張する人は、おそらくEFを適切に使用する方法を学ぶべきだということです。

だから、あなたはあなた自身のORMを書く必要がありますか？

私はそれを提案しません。プロレベルのORMはすでに存在します。つまり、次の場合にのみ独自のORMを作成する必要があります。

• 既存のすべてのORMが何らかの理由で適合できない正確なコンテキストがあり、
• 既存のORMを学習する代わりに、独自のORMを作成して使用するコストがはるかに低いことは間違いありません。これには、将来のサポートのコストが含まれます。これには、ORMの使用方法を理解するために技術文書の数百ページを読む必要がある別の開発者チームによるものも含まれます。

もちろん、物事を学ぶために、好奇心だけで独自のORMを書くことを禁じるものはありません。ただし、商用プロジェクトでは実行しないでください。

ホイールを再発明し、後悔しないという質問に対する私の回答のポイント2から3も参照してください。車輪を再発明するさまざまな理由がここでは当てはまらないことがわかります。

通常のCRUDのすべて（コードの80〜95％）にEntity Frameworkを使用し、最適化が必要な残りのコードにはカスタムデータアクセスコードを使用します。 これは、あなたが十分にコントロールできないと主張している人々の懸念を満たす必要があります。

そもそもそのコードを生成するのに必要な独自のコードを書くことで、少なくとも時間と労力を節約できることを（少なくとも合理的に）確信できる場合に限り、それは良い考えです。状況によっては、スケジュールを変更することもスケジュールに影響を与える可能性があり、それも考慮に入れる必要があります。また、長期メンテナンスを方程式に含める必要があります。独自のORMをロールする場合、永久に（または少なくとも使用する限り）維持する必要があります。

一番下の行は、適切な条件下で、それが意味をなすことができるということです。これらの条件には一般に次が含まれます。

1. 作業中のプロジェクトは非常に大きいため、大量の使用に対して費用は償却されます。
2. データの使用は非常にまれであるため、既存のライブラリ（およびそのような）は、目的に対して非常に不十分に動作します。

明らかなことを述べるリスクはありますが、これら2つは逆の関係にあります-本当に巨大なプロジェクトに取り組んでいる場合、個々の使用でわずかな節約であっても、開発を正当化するのに十分な量になります。逆に、ニーズが本当に珍しいため、使用するたびに多くの利益を得られる場合、かなり小さなプロジェクトでも作業が正当化される可能性があります。

ただし、少なくとも説明に基づいて、どちらも実際には当てはまりません。おそらく、1つ（または両方）が同僚の以前のEFの使用に適用されていたのか、それとも彼は偏見を抱いていました-どちらを推測するのに十分な情報を与えられたとは思いませんか（公平さではあるが、 dは、推測するのに十分なほどあなたに言っていないからだと思います）。

私がこの状況を担当した場合、私はあなたとあなたの同僚にそれぞれ種類のポジションペーパーを書くと思います-各アサーション/主張をサポートする本当の証拠とともに、あなたが各アプローチで見る強みと弱みのリスト/なんでも。その後、チーム全体が各論文を批判します（つまり、必須となる）。彼らの批評の第一のポイントは、2つのスケールで各ポイントを評価することです。

1. ポイントが正確であるように見える度合い、事実などによって十分にサポートされている
2. ポイントが手元のプロジェクトに適用されるように見える程度。

その後、私は論文と批評を評価して決定を下します（完全に正直ですが、どれだけそれらを使用して決定を下し、どれだけ使用して決定を正当化するかを言うのは難しいかもしれません）私はすでに作った-私はおそらくそれを認めるべきではないことを知っていますが、現実は私も人間だということです...）

編集：

特に厄介な（または「教育的」-この場合の違いを見分けるのが難しい）場合は、既存のORM / DALの使用と開発の両方の全体的な開発作業の見積もりを作成してみてください。あなた自身の。それは単なる推測に過ぎませんが、私が即座に推測することは、自分でロールバックするための壮大な計画を立てている人のほとんどは、彼らの見積もりを変えることを気にしません-彼らがリモートでさえ終わった全体的な努力の見積もりを考え出すまでに（そして現実的）、彼らは既存のコードの使用と競合する方法に近づきさえしなかったことに気付くでしょう。同時に、それは

編集2：（@CmdKeyの提案の一種）：明示的に言及されていませんが、推定には暗黙的にリスクの評価が含まれると思います。特に、時間の推定には通常、PERTスタイルの数値を含める必要があります。

1. すべてがうまくいけば、最速のベストケースの推定を行うことができます。
2. 「通常の」見積もり-予想される所要時間。
3. すべてがうまくいかなかった場合にかかる可能性がある最長の最悪ケースの推定値。

もちろん、ベストケースとワーストケースの推定値には通常、直接的な神の介入のようなものを含めるべきではありませんが、それ以外のものはほとんど含めるべきです。

通常、車輪を再発明することは決して良い考えではありません。そして、それを行うことは通常、技術的な無知（「私は他に何も知らず、学びたくない」）またはor慢（「Xは愚かです、私はできる2週間で独自のツールを作成してください！ "; いくつかの平均的な開発者が数週間で一緒にハッキングできるものよりもはるかに良いことができる成熟したツールがあります。

ただし、多くの作業をせずに、既存のソリューション（柔軟性に関係なく）にレガシーアプリケーションを確実に適合させることができない場合があります。このような場合、それは「良い」アイデアではなく、代替案（つまり、そのままにしておくか、サードパーティレイヤーを使用できるように半分を書き換える）よりも良いアイデアなので、選択肢はほとんどありません。

Hibernateには存在しない「重要な」機能があるため、私は既存のJava ORMツールを拒否して独自のツールを作成するプロジェクトに参加していました。これは数百万ドルの間違いであり、コストは日々増加しています。彼らはまだオブジェクトの関係を完全にサポートしていません。そのため、フレームワークの作成と保守に費やされるすべての時間に加えて、Hibernateを使用して数分で記述できるコードを記述するのに何時間も費やしています。

既存のフレームワークは、数十人年の努力の成果です。単一のチームが数週間でどこにでも近づくことができると想像するのはばかげています。

記述しなければならないコードは、維持する必要があるコードです。ORMコードの保守に費やされる時間は、アプリの保守に費やされない時間です。ORMが何らかの戦略的優位性を提供しない限り、それはビジネスのためのお金を生み出すものではないので、純粋なオーバーヘッドです。あなたの会社は、むしろオーバーヘッドにお金を使うか、金moneyけ製品を強化するでしょうか？これが内部アプリ用である場合、これは問題ではない可能性がありますが、作成、テスト、および文書化する必要があるコードの量はまだ増加しています。

あなた自身のORMを展開するのは悪い考えだと思います-あなたがそうする非常に非常に神の理由がない限り（ところであなたが引用したものは十分ではありません:)

ORMを使わないように他の人に納得させるというミスを一度しましたが、すべてのDALを書くと本当に遅くなり、DALに時間を費やしていたビジネスにとって重要な機能を実装する代わりに、見た目よりも）。

新しいEFのsemは非常に優れていますが、さらに制御したい場合は、Drapper http://code.google.com/p/dapper-dot-net/またはPetaPOCO httpのようなマイクロORM / sを見てください：//www.toptensoftware.com/petapoco/

組み合わせて使用​​することもできます-EFを使用して大部分を調整し、Drapperを使用して微調整します。

とにかくそれは私の2cです;）