language-agnostic - ORM への切り替え

Question

ORM をサポートするアプリケーションに段階的に組み込むというアイデアをいじっています。アプリはあまり構造化されておらず、単体テストはありません。したがって、変更にはリスクが伴います。私は明らかに、変更するのに十分な理由があることを心配しています. データアクセス用のボイラープレートコードが少なくなり、生産性が向上するという考え方です。

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

score 3 · Accepted Answer

Michael Feather の著書Working Effectively With Legacy Code ("Legacy Code" Feathers とは、単体テストで十分にカバーされていないシステムを意味します) のコピーを入手することを強くお勧めします。リファクタリングやベストプラクティスの段階的な導入に役立つ優れたアイデアが満載です。

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

ORM のマイナス面 - 経験から、選択した ORM ソリューションの概念、構成、および特異性を把握するには、必然的に多少の学習曲線が必要です。

編集：修正された著者の名前

score 2 · Accepted Answer

実際にマイケル・フェザーズによって書かれた「ロバート・C・マーティン」の本（「アンクル・ボブ」は、最近のブランド名のようです！）は必見です.

途方もなく時間がかかることは言うまでもなく、単体テストを使用して開発されていないアプリケーションに単体テストを配置することは、ほぼ不可能です。コードは従順ではありません。

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

大きなチャンクから始めます。反復可能な実行を設定し、後続の実行で期待される結果として何が起こるかをキャプチャします。これで、アプリ、または少なくともその一部のテストが完了しました。確かに、非常に優れた包括的なテストではありませんが、これは始まりであり、そこから改善するしかありません.

これで、リファクタリングを開始できます。データアクセスコードの抽出を開始して、あまり邪魔されずに ORM 機能に置き換えることができるようにします。頻繁にテストしてください: レガシーアプリでは、何が壊れているかに驚かれることでしょう。結束と結合は、本来あるべきものになることはめったにありません。

また、Martin Fowler のRefactoringも検討したいと思います。これは明らかに、このプロセスに関する決定的な作業です。

score 1 · Accepted Answer

最近NHibernateを使い始めた大規模なASP.netアプリケーションに取り組んでいます。手動で保持していた多数のドメインオブジェクトを Sql Server に移動し、代わりに NHibernate に移動しました。それは物事をかなり単純化し、時間の経過とともに物事を変更することをはるかに容易にしました. 変更を行い、多くの新しい作業に適切な場所で NHibernate を使用していることを嬉しく思います。

score 0 · Accepted Answer

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

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

ORM は定型コードを減らすように設計する必要があります。エンタープライズになるための時間/トラブル対ROIは、あなた次第です:)

score 0 · Accepted Answer

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

score 0 · Accepted Answer

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

それ以外では、ORM は優れた方法であり、間違いなく検討する必要があります。

score 0 · Accepted Answer

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

アーキテクチャが不十分なコードで単体テストのセーフティネットを構築しようとしても、成功が保証されるわけではありません。それを変更しても安全だと感じるだけです。

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

language-agnostic - ORM への切り替え

7 に答える 7

Related

Reference