10

ユーザー インターフェイス コードをドメイン コードから分離しておくことが重要であることはわかっています。アプリケーションは、理解しやすく、保守しやすく、変更しやすく、(場合によっては) バグを特定しやすくなります。しかし、ここに私のメンタルブロックがあります...

Delphi には、私が望むことを行うメソッドを備えたコンポーネントが付属しています。たとえば、RichText Memo コンポーネントを使用すると、リッチ テキストを操作できます。TMS の文字列グリッドなどの他のコンポーネントは、私が望むことを実行するだけでなく、機能に対して追加料金を支払いました。これらの機能により、R は RAD に配置されます。

他の誰かがすでに私のために行ったことを行うために、私自身のクラスを書くのは非論理的です。これは車輪の再発明です [リッチ テキストを直接操作したことはありますか? :-) ] しかし、このようなコンポーネントに組み込まれた機能を使用すると、多くの UI とドメイン コードが混在することになります。ほとんどのコードがイベント ハンドラに組み込まれたフォームができてしまいます。

この問題にどう対処しますか？... または、他の人が既に私のために書いたコードを引き続き使用したい場合、問題にどのように対処することをお勧めしますか?

4

2 に答える 2

6

まず、「リッチ テキストを処理する」ことは、アプリが行うべきことではないことを覚えておいてください。アプリは、ユーザーが特定のタスクを実行できるようにするものであり、そのタスクを処理するコードがドメイン ロジックです。プログラムで実行する必要があるタスクの一部にリッチ テキストの操作が含まれる場合、その部分をリッチ テキスト コンポーネントに委任できます。おっしゃったように、複雑なのはこれらのライブラリとドメイン ロジックの間のインターフェイスにあります。

Delphi ドメイン ロジックと Delphi UI コントロールが相互に対話する方法は、主にイベント ハンドラを介して行われます。ただし、これは、ドメイン ロジックをイベント ハンドラー自体に配置する必要があるという意味ではありません。代わりに、実行する必要があるドメイン固有のタスクのコードを含むユニットを作成し、イベント ハンドラーがそれらのユニットを呼び出すようにしてください。

言い換えれば、車輪を再発明するためにクラスを作成したり、他の人がすでにあなたのために行ったことをしたりしないでください。そうです、それは非論理的です。しかし、使用するコントロールとライブラリが提供していないアプリケーション固有の部分を、独自の個別のユニットで独自の個別のクラスとして記述し、フォームのイベント ハンドラーとパブリック メソッドまたはプロパティを介してそれらを接続すると、最終的には適切な関心の分離。

于 2010-04-20T20:50:40.947 に答える
1

datamodules を clientDataSets と共に使用して、ビジネス ロジックとデータ オブジェクトを含めることにより、かなり明確な分離を作成できます。さらに一歩進んで、ビジネス ロジックをデータから分離することもできます。明らかに、フォームには UI が含まれています。使用するほとんどすべてのコンポーネントをデータ バインドできるため、それらを clientDataSet に簡単にバインドできます。

Delphi には、Java や .Net のベスト プラクティスに常に適合するとは限らないことを行う方法があることを覚えておいてください。あなたの目標は、適切だと感じられ、Delphi で機能することを行うことです。

于 2010-04-20T22:58:50.893 に答える