ORM への切り替え

Question

私は、サポートするアプリケーションに ORM を段階的に導入するというアイデアを検討しています。このアプリはあまり構造化されておらず、単体テストもありません。したがって、どんな変化もリスクを伴います。私は明らかに、変更する十分な理由があるかどうかを懸念しています。データ アクセスのための定型コードが減り、生産性が向上するという考えです。

これはあなたの経験に当てはまりますか?
段階的に導入することは可能ですか、それともそれが良い考えですか?
ORM の欠点は何ですか?

Answer 1

マイケル・フェザーの本を入手することを強くお勧めします。 レガシーコードを効果的に使用する (「レガシー コード」のフェザーとは、単体テストで適切にカバーされていないシステムを意味します)。リファクタリングやベスト プラクティスの段階的導入に役立つ優れたアイデアが満載です。

確かに、最初はドメイン モデルの一部のサブセットにアクセスするために ORM を使用して、段階的に ORM を導入することもできます。そして、はい、ORM を使用すると開発時間が短縮されることがわかりました。これは重要な利点の 1 つであり、データ アクセス レイヤーを苦労して手作りしていた時代を懐かしく思うことはありません。

ORM の欠点 - 経験上、選択した ORM ソリューションの概念、構成、特異性を理解するには、必然的に少し学習曲線が必要になります。

編集：著者名を修正しました

Answer 2

マイケル・フェザーズ（「アンクル・ボブ」は最近のブランド名のようです！）が実際に書いた「ロバート・C・マーティン」という本は必読です。

単体テストを使用して開発されていないアプリケーションに単体テストを組み込むことは、非常に時間がかかることは言うまでもなく、ほぼ不可能です。このコードは適合しません。

しかし、それは問題ではありません。リファクタリングとは、機能を変更せずにデザインを変更することです (意味を大きく壊していないことを願っています)。これにより、より幅広い方法で作業できるようになります。

大きな塊から始めてください。反復可能な実行を設定し、その後の実行で予想される結果として何が起こるかをキャプチャします。これで、アプリ、または少なくともその一部がテストされました。確かに、あまり良いテストや包括的なテストではありませんが、これは始まりであり、物事はそこからさらに良くなる可能性があります。

これで、リファクタリングを開始できます。データ アクセス コードの抽出を開始して、あまり支障をきたさずに ORM 機能に置き換えることができるようにしたいと考えています。頻繁にテストしてください:従来のアプリでは何が壊れるか驚くでしょう。凝集性と結合性が実際のものになることはほとんどありません。

Martin Fowler のものも検討してみます。 リファクタリング, 明らかに、これでプロセスの最終的な作業としては十分です。

Answer 3

私は最近 NHibernate を使い始めた大規模な ASP.net アプリケーションに取り組んでいます。SQL Server に手動で永続化していた多数のドメイン オブジェクトを、代わりに NHibernate に移動しました。これにより、物事がかなり簡素化され、時間の経過とともに物事を変更することがはるかに簡単になりました。私たちは変更を加えたことを嬉しく思い、多くの新しい作業に適切な場合には NHibernate を使用しています。

Answer 4

TypeMock はレガシー コードのリファクタリングによく使用されていると聞きました。

Answer 5

私は、レガシー アプリケーションに ORM を導入すると、トラブルが発生すると真剣に考えています (そして、完全に書き直すのと同じくらいのトラブルになる可能性があります)。

それを除けば、ORM は優れた方法であり、ぜひ検討する必要があります。

Answer 6

リファクタリングのルールは次のとおりです。単体テストを実行します。

したがって、おそらく最初に、少なくともコア/主要なものに対していくつかの単体テストを配置する必要があります。

ORM は定型コードを減らすように設計する必要があります。時間/トラブル vs.企業としてのROIはあなた次第です:)

Answer 7

コードがすでにモデル層バックエンドの「ホットスワップ」を可能にするアーキテクチャになっていない限り、何らかの方法でコードを変更することは常に非常に危険です。

設計が不十分なコードに対して単体テストのセーフティ ネットを構築しようとしても、成功が保証されるわけではありません。コードを変更する際に安心感が得られるだけです。

したがって、関連するリスクを引き受ける強力なビジネスケースがない限り、おそらく十分に放っておくのが最善です。