コードをさまざまなフォルダーと名前空間に分割する最適な方法を決定する

Question

次のディレクトリがあります:

-UI
-ビジネスの論理
-データアクセス
-ビジネスオブジェクト

サーバーシステム上の状態を変更するサーバー側サービスへのクライアントスタブであるクラスがある場合、それはどこに行くでしょうか。。

Answer 1

このコードはごみ箱にあります ;-)

真面目な話、自分で書いたもののどこに行くかわからない場合は、コードに問題があるか、パーティショニングに問題があるかのどちらかです。私たちがあなたのシステムについてあなたよりも多くの情報をどうやって知ることができるのでしょうか?

情報に基づいていない意見が必要な場合は、ペタバイト単位で収集した意見をご覧ください。

1. それはクライアントスタブだと言ったので、UIに表示されます
2. ビジネス ルールの効果を実装するため、ビジネス ロジックに組み込まれます。
3. 状態が変化するサービスにアクセスしているため、データ アクセス層に入ります。
4. サーバー上の状態が変化するため、ビジネス オブジェクト層に入ります。

スタブが実際に何をするのか教えていただけるとさらに助かります。詳細がなければ、それがどこに属するのかを知るのは難しく、および/またはそれがどこに「属するべき」かについて真空で議論するのは簡単です

Answer 2

それはあなたがあなたのデータアクセスクラスの残りの部分と同じプロジェクトでそれを配置する必要があると私にははっきりしないが、

私は、このデータ・アクセスの形を検討します。層は主に概念的なものであることを忘れないでください - あなたはクリーンなデザインを保つのを助けるために。別のプロジェクトにそれらを分離することにより組織的に役立ちますが、必須ではありません。それは実際のスタブクラスの場合は、データアクセスのプロジェクトは、おそらくそれのための自然な家ですが、それは唯一のUI層に使われている場合は、そこにそれを維持することは、おそらく大丈夫でしょう。

Answer 3

私はそれがそれらのいずれかに属しているとは思いません。あなたは、どちらかの新しいディレクトリやまったく新しいプロジェクトが必要です。それははあなたの説明によると、のデータにアクセスし、むしろ単にローカルオブジェクト（スタブ）のように作用されます。

確かではありませんので、しかし、与えられたもののうち、私は、BusinessObjectsを言わなければならないでしょう

Answer 4

Webサービスリポジトリでます。