1

...次は何ですか？

どのアクターがどのアクションを実行するかを定義した後、どのように進みますか？データベースをモデル化しますか、それともクラスから始めますか？

オブジェクト間の関係に焦点を当てるために、クラスのようなモデリング図から始めるのがより良いアプローチだと思いました。クラスの詳細を深く掘り下げすぎたため、これは間違っていることがわかりました。システムが「機能しているように見えた」としても、データベースモデリングに進むと、前のフェーズで選択した位置にすべてが自然に収まりませんでした。

クエリされて基になるデータベースの抽象化を提供する大きなオブジェクトをメモリ内に構築するのではなく、アプリケーションロジックをデータベースに配置し、その速度を利用してデータを取得する必要があるという人々の話を読みました。私はいつも、データベースが私のデータを保存し、それにアクセスするための高速な方法を提供するためにあると思っていました。しかし、私は間違っているかもしれません。つまり、クラスのグループに配置するのと同じロジック内にデータベースを構築する必要があるのでしょうか。データベースには、これを実現するためのツールが不足していませんか？

どこから始めればよいかわからないと思います。データベースから始めることを選択した場合、それを「データを保存する場所、より高いレベルでアプリロジックを実行しよう」と考えるだけでは難しいと思います。 「クラスから始めると、データベースがクラスの不自然な表現のように見えてしまうので、適切なツールに適切な目的を割り当てていないなど、重要な何かを見逃しているような感覚を感じます。

これにどのように対処しますか？dbとクラスのどちらのモデリングから始めるかを決定する場合、あなたの経験では、どのようなアプローチが自然でクリーンな実装につながることが証明されていますか？

前もって感謝します

4

2 に答える 2

2

Robustness Analysisを使用して成功しました。

この記事では、ロバスト性分析に焦点を当てます。これには、ユース ケースの説明テキストを分析し、各ユース ケースに参加するオブジェクトの最初の推測セットを特定し、これらのオブジェクトを次の 3 つのタイプに分類することが含まれます。

  1. アクターがシステムとの通信に使用する境界オブジェクト。
  2. 通常はドメイン モデルのオブジェクトであるエンティティ オブジェクト (2001 年 1 月の「Driving Design: The Problem Domain」の主題)。
  3. コントロール オブジェクト (実際のオブジェクトではないことが多いため、通常はコントローラーと呼ばれます) は、境界オブジェクトとエンティティ オブジェクトの間の "接着剤" として機能します。図 1 は、これら 3 種類のオブジェクトの視覚的なアイコンを示しています。

エンティティ オブジェクトは、(通常) データベースに格納されるオブジェクトです。

クラスとデータベース間のマッピングについては、「The ORM Problem」に関する S.Lott の記事をお勧めします(彼は StackOverflow の参加者でもあります)。

于 2009-04-30T12:39:46.830 に答える
1

テスト駆動開発を使用している場合は、最初に単体テストを記述します。あなたのクラスは、あなたが行くにつれて概説されます。

データベース (モックまたはスタブ オブジェクト) を使用せずにビジネス ロジックを開発するか、テストを進めながらデータベースを開発するかを選択できます。

データベースとドメイン モデルは互いに 1 対 1 で対応付けるべきではないことに注意してください。

于 2009-04-30T12:00:55.053 に答える