.net - CRUD の設計、実装、維持に費やされた労力

Question

データ アクセス層での単純な作成、読み取り、更新、および削除 (CRUD) メソッドの実装と維持に、総開発作業の何パーセントを費やしていますか?

Hibernate や Entity Framework などの ORM に移行すると、大幅な節約につながりますか? データ アクセス レイヤーの ORM への移行が適切な選択であることを知らせる設計上の匂いはありますか?

敬具、アシッシュ

Answer 1

最近、ORM なら数分でできることを再現するために途方もない時間 (おそらく 40% 程度) を費やしたので、十分にテストされたフレームワークが基本的な CRUD 操作を生成 (および維持!) できるようにできるときはいつでも、LET と言わざるを得ません。やりなさい！

フレームワークにそれが得意とすることをさせてください。実際に価値を付加するアプリケーションの部分、つまり解決しようとしているビジネス上の問題に時間を費やしてください。フレームワークが不足している場合にのみ、それを回避することを本当に検討する必要があります。「不十分」にはパフォーマンスが含まれる場合がありますが、通常、フレームワーク内には、必要なことを実行できるようにするための「フックとノブ」があります。

実装/設計のにおい: 'StoredProcedureWrapper' を 40 回コーディングした場合、または DAO 出力をキャプチャしてクエリ結果のキャッシュを実装している場合は、ORM を使用できる/使用する必要があります。

Ruby/Rails または Groovy/Grails タイプのフレームワークでは、どちらの環境でもドメインが生成されるため、ORM レイヤーから始めない本当の理由がわかりません。

Spring/Hibernate を使用すると、もう少し複雑になりますが、非常によく似た小さなクラスのハンドコーディングを大幅に節約できます。

また、過去 10 年間のいくつかのプロジェクトで、ORM の使用を開始しなかった場合、JDBC フレームワークやその他の足場コードを開発または「盗用」することになり、ORM でできることの多くを再び複製することを発見しました。あなたを取得します。