6

保守している Web アプリケーションにいくつかの機能を追加する必要があり、アプリケーションが必要とする新しいデータを保存および取得するために、データベース (Sql Server 2010) を変更するためのパスを決定する必要があります。

「醜いが速い」パス:
Web アプリケーションには、ドメイン フィールドを指定して、ストアド プロシージャを介して取得およびフィルター処理できるさまざまなドメイン データを格納する、この「汎用ドメイン テーブル」が既にあります。
何かのようなもの：

| Id         | Description | Domain       |
|------------|-------------|--------------|
| 001        |    Apple    |     Fruit    |
| 002        |    Peach    |     Fruit    |
| 003        |    Banana   |     Fruit    |
| A01        |    Yellow   |     Color    |
| A02        |     Red     |     Color    |
| A03        |     Green   |     Color    |


SP_GetDomainValues @Domain='Fruit'

テーブルには、手間をかけずにデータを保存および取得するためのアプリケーション層が既にあります。
必要なのは、データベース スクリプトを作成して、必要な新しいレコードと適切な新しいドメインをテーブルに入力することだけです。
このアプリケーションには、それぞれが 1 つのドメインのみを格納する複数のドメイン テーブルもあることに注意してください。

「良いが遅い」パス:
データを保存および取得するために、さまざまなテーブル、ストアド プロシージャ、および DAL メソッドを作成する必要があります。

個人的には、次の 2 つの主な理由から2 番目のアプローチが好きです。

  • 1 つの大きなテーブルのサブセットではなく、テーブルに自然に結合するため、クエリでデータを使用する方がはるかに簡単です。

  • データは非常に自然に外部キー制約を使用して検証できますが、おそらく「genericDomain」という名前のテーブルが 1 つある場合、これは実現できません。完全に可能ではないというわけではありません。制約を使用するのは面倒です

どちらを選択するかを決定するのに役立つある種の厳格な比率がなければ、毎回迅速で汚い道をたどることになると私は思う傾向があります.

経験上、第一選択は設計が悪いのか、罪悪感なく使える場合があるのか​​？

4

2 に答える 2

4

データを追加するだけで仕事を終わらせることは、たとえ「完璧」でなくても、私にとっては素晴らしいことのように思えます。

また、「優れた」設計には、スキーマの変更、新しいコード、およびテストが必要であり、これらはすべてコストがかかり、リスクを伴うことも考慮してください。

于 2012-11-06T11:58:15.127 に答える
1

いつものように、それは異なります。

アプリケーションが機能していて、機能が強化されていない可能性がある場合は、すばやく汚いことをして、生活を続けることができます。それが最も速くそして最も簡単に予測されるルートであるので、ビジネスはおそらくあなたに感謝するでしょう。コードを見つけたよりも良い状態にしないことについては気分が悪くなりますが、次にもっとや​​りがいのあることに取り組むことができれば幸いです。

アプリケーションにバグがある場合、または将来さらに機能を追加する必要がある可能性がある場合、またはこれの長期的な保守所有者である場合は、これを使用することの将来の苦痛をトレードオフする必要がありますそれをより維持可能な状態にすることの短期的な苦痛に対するモデル。

@a_horse_with_no_nameが書いているように、あなたが概説するデザインはよく知られているアンチパターンです。それはもろいです-データの変更は、あらゆる種類の刺激的な方法でアプリケーションを壊す可能性があります。基盤となるデータストレージメカニズムをすべて理解し、「フルーツ」の正しい単語（大文字と小文字、スペル、不正なスペースを含む）を覚えることができる、さまざまなレイヤーに依存しています。データの有効性をチェックするためにアプリケーションロジックに依存しています-参照整合性はありません-ほとんどの場合、これはどこかで失敗するため、無実のエンドユーザーは正しいと思う値を入力しますが、それは何らかの方法でルールを破り、永遠に続きます失った。

したがって、このコードをしばらく使用する必要がある場合は、リファクタリングを検討します。まず、既存のコードの単体テストと統合テストを作成し、アプリケーションの一部を徐々にリファクタリングして、より合理的なデータベースモデルを使用するようにします。アプリケーション全体の変換には元のビルドと同じくらいの時間がかかる可能性があり、ほとんどのビジネスマンは、いくつかの単純な追加機能を追加すると全体の再構築が必要になると聞いて喜ぶことはありません。行きたい！

于 2012-11-06T13:09:26.537 に答える