3

一部のプロジェクトでは、Dbの制約を壊さずにビジネスロジックを続行するために、Dbで作成するダミーレコードが必要であることがわかりました。

これまでのところ、2つの方法でその使用法を見てきました。

  • IsDummyのようなフィールドを追加することによって
  • タイプを指すObjectTypeと呼ばれるフィールドを追加することによって：ダミー

わかりました、それは達成する必要があるものに役立ちます。

しかし、そのような解決策について私が警戒しているのは、いくつかのプロセスで処理する必要のあるダミーレコードがアプリケーションに存在することを覚えておく必要がある場合があります。そうでなければ、彼らの存在に気付くまで、またはチームの誰かがあなたに「ああ！あなたはダミーの記録を忘れました。あなたもするべきです...」と言うまで、あなたはいくつかの問題に直面します。

したがって、問題は次のとおり です。Dbに文句を言わせずに、ビジネスロジックをそのまま維持するためにダミーレコードを作成するのは良い考えですか。はいの場合、開発者が自分の存在をスキップするのを防ぐためのベストプラクティスは何ですか？そうでない場合は、ダミーレコードを作成する唯一のオプションになってしまう状況に陥らないようにするために何をしますか？

ありがとう！

4

8 に答える 8

6

ダミーレコードを使用することは、制約を正しく取得することよりも劣ります。

ダミーレコードを使用すると、新しい機能を提供するための最速の方法のように見えるため（場合によってはそうなることもあります）、それらを使用したくなることがよくありますが、ドメインロジックとデータの違いを隠すため、優れた設計の一部にはなりません。モデル。

于 2010-11-10T16:57:46.037 に答える
5

ダミーレコードが必要になるのは、モデラーがデータベース定義を簡単に変更できない場合のみです。つまり、定義やデータモデルがかなり悪い場合です。データベース内の特殊なケースを処理するために、アプリ層に特殊なコードが必要な状況に陥ることは決してありません。それは保証されたメンテナンスの悪夢です。

適切な定義またはモデルであれば、「既存のコードに影響を与える」ことなく、簡単に変更できます。

[データベースで定義されている]すべてのビジネスロジックは、ANSI SQLの制約、チェック、およびルールを使用して実装する必要があります。（もちろん、下位レベルの構造はドメイン/データ型などによってすでに制約されていますが、「ビジネスルール」として分類することはしません。）それを行うだけで、ダミーを実装する必要がなくなることはありません。

それができない場合、モデラーは知識と経験を欠いています。または、正規化などのより高いレベルの要件が破られており、それらに依存する制約を実装する際の障害となります。また、モデラーが失敗したことを意味します。

このような制約を破ったり、ダミーレコードを追加したりする必要はありませんでした（そして、非常に多くのデータベースで作業しました）。他の人が作成したデータベースを作り直したときに、ダミーレコード（および重複）を削除しました。

于 2010-11-11T04:26:29.447 に答える
4

私はこれをしなければならないことに出くわしたことがありません。これを行う必要がある場合は、データ構造に問題があり、レポート作成のさらに先で問題が発生します...

于 2010-11-10T16:59:32.170 に答える
4

ダミーを使用するのはばかげています。

一般的に、あなたはそれらなしであなたの論理を正しくすることを目指すべきです。私もそれらが使用されているのを見ましたが、それは緊急の解決策としてのみです。あなたの説明は、それを標準的な慣習にするように聞こえます。それはそれが解決するよりも多くの問題を引き起こすでしょう。

于 2010-11-10T17:01:32.577 に答える
3

「ダミー」レコードを追加するために私が見ることができる唯一の理由は、あなたがひどく悪いアプリとデータベースの設計をしているときです。

それは間違いなく一般的な習慣ではありません。

ビジネスロジックが既存のレコードに依存している場合は、次の2つのいずれかを実行する必要があります。そのロジックを実行する前に、正しいレコードが作成されていることを確認します。または、不足している情報を考慮に入れるようにロジックを変更します。

于 2010-11-10T17:00:39.100 に答える
2

正しい解決策は、ビジネスロジックを更新することです。

拡張された説明を引用するには：

Packageオブジェクトがあり、コンテンツのないPackageを作成できないビジネスロジックを実装していると仮定します。YOuは、いくつかのビジネスレイヤールールを作成し、関連する制約を使用してDbを設計しました。しかし、数年後、新しい機能が要求され、それを達成するには、コンポーネントなしでパッケージを作成できる必要があります。これを克服するために、UIには表示されないが、空のパッケージを作成できるダミーコンテンツを作成することにしました。

そのため、コンテンツのないパッケージへの一度は無効であったため、ビジネスレイヤーはパッケージオブジェクト内にコンテンツの存在を強制しました。それは理にかなっている。現実世界のシナリオがそのように変更された場合、コンテンツなしでパッケージオブジェクトを作成する正当な理由が必要になります。変更する必要があるのはビジネスロジックレイヤーです。

ほぼ普遍的に「ダミー」をどこでも使用することは悪い考えであり、通常は実装の問題を示しています。この例では、ダミーデータを使用して、ビジネスの実際の制約を正確に表していないビジネスレイヤーへの「コンプライアンス」を可能にしています。

コンテンツのないパッケージが有効でない場合、ビジネスレイヤーへの「準拠」を可能にするダミーデータは愚かなハックです。本質的に、あなたはあなた自身のシステムを保護するためのルールを書き、それからあなた自身の保護をどのように回避しようとしているのか。一方、コンテンツのないパッケージが有効である場合、ビジネスレイヤーは偽の制約を強制するべきではありません。どちらの場合も、ダミーデータは有効ではありません。

于 2010-11-10T21:27:50.093 に答える
2

「ビジネスロジック」として何かを簡単に区別できない状況は、より良い方法を考えようとする原因だと思います。

「タイプを指す：ダミー」とおっしゃっているという事実から、データアクセスの処理に何らかのORMを使用していると思います。NHibernateのようなORMソリューションの非常に優れたチェックポイント（唯一ではありませんが）は、ソースコードがアプリケーションを駆動するデータ構造を非常に明確に記述していることです。これにより、データアクセスをソース管理下で簡単に管理できるだけでなく、問題が発生した場合のデバッグも容易になります（問題が発生したかどうかではなく、いつ発生したかは問題ではありません）。

ダミーレコードのようなある種の「松葉杖」を導入するとき、データベースの要点を無視していることになります。この種のものの必要性を排除するために、データベースはデータに対してルールを適用するためにあります。この種の手法に頼る前に、まずアプリケーションロジックを確認することをお勧めします。あなたの仲間の開発者、または新入社員について考えてください。機能を追加して、小さな「ダミーレコード」ロジックを忘れる必要がある場合はどうなりますか？

あなたは不安を感じてあなたの質問の中であなた自身に言及します。あなたの腸で行きなさい。ダミーレコードを取り除きます。

于 2010-11-10T17:01:19.610 に答える
2

私はここで共通の感覚を持って行き、ダミーの記録に反対しなければなりません。

何が起こるかというと、新しい開発者はそれらについて知らず、それらを処理するためのコードも作成しないか、テーブルを削除して新しいダミーレコードを追加するのを忘れます。

私はレガシーデータベースでそれらを経験し、上記の両方が発生するのを見てきました。

また、それらが長く存在するほど、それらを取り出すのが難しくなり、これらのダミーレコードを考慮に入れるために、より多くのコードを作成する必要があります。

于 2010-11-10T17:12:23.327 に答える