質問: 私は大規模なプロジェクト、そして迷路を継承しました。このトラフィックはデータアクセスを最適化するのに十分なほど充実しているので、私はJavaScriptから呼び出されるWCFサービスをWeb APIに変換し始めました。 残念ながら、データベースの主キー(自動インクリメントではない)は、使用される次のIDのセットを返すMySQL関数を照会することによって、カスタムORMによっても管理されます。 ORMはそれらをキャッシュし、アプリケーションに提供します。データベースそのものは2 TBのデータがますます増大しており、ダウンタイムを大幅に削減します。 私はDapperを使いこなす予定だったが、過去には簡単にパフォーマンスを楽しんだが、このカスタムORMからこのデータベースを守るのは難しく、エラーになりやすいようだ。 質問: * 誰もが大規模なプロジェクトに取り組むためのアドバイスを持っていますか? * データベースをまったく新しいデータ構造に移行することにもっと焦点を当てるべきですか? (これもかなりの正規化が必要です!)
回答: **私の謙虚な意見** : 従来のコードを扱う際の経験則は*、何か問題*が*なければ、そのようにしてください。必要に応じて、変更または改善を行い*ます。主な理由は次のとおりです。 * システムにビジネス価値を追加する場合、再設計の効果はほとんどゼロです。 * システムは、良いか悪いか、動作します。あなたが持っているケアに関係なく、あなたはいつも構造的な変化で何かを混乱させることができます。 また、会社の計画には、変更する理由(機能の追加、バグの修正、デザインの改善、リソースの使用の最適化など)が大きく左右されます。私の謙虚な経験から、時間と予算は非常に重要であり、私たちはいつも再設計したい(または場合によってはゼロからコード化する)ことを望んでいますが、最も重要なことはビジネス目標と付加価値です。 あなたの場合は、すべてのORMを変更する必要はないかもしれません。 IDがキャッシュされていると言えば、より良いアプローチは、PKを変更してIDプロパティ(各テーブルの適切な開始値)を追加することです。その後、次のIDを取得するコードの特定の部分を削除することができます。 場合によっては、正規化されていないデータベースには理由があります。パフォーマンスに影響する結合を避けるためにデータをテーブルにコピーするケースがあります。私は数百万の記録を話している... ORMを変更する理由:効率が悪い場合や、アンマネージコードを閉じない場合(この場合は、IDisposableインターフェイスを実装する方が良い)それがうまくいく場合は、新しい機能を作成する必要がある場合は、新しいORMを使用する方がよいでしょう。プロジェクトが最適化のためにリファクタリングを必要とする場合、コード全体ではなく、ボトルネックに変更を適用する必要があります。 トピックについて多くの議論があります。お勧めのリソースは、Michael Feathersの「従来のコードを効果的に使用する」またはEric Evansが「Legacy Systemsに囲まれたときにDDDを始める」です。 ご挨拶!