だから私はwinforms C#ソリューションを再編成して、分離してよりクリーンで整理するのに役立てています。このソリューションは、中小企業の注文などを追跡します。.
これまでのプロジェクトを
App.View - すべての GUI 関連コード
App.Data - データ構造とインターフェイスのみ。他の実装コードなし
App.BusinessLogic - GUI 参照を持たないすべてのビジネス ロジック コード
どこに属しているのかわからないクラスがいくつかあります。各クラスがどのプロジェクトに行くべきか、またはこのために作成すべき別のプロジェクトがあるかどうかについて、あなたの考えを教えてください。
実際、あなたは伝統的な階層化されたアーキテクチャから少し離れていると思います。通常、アプリケーションが処理するデータのモデルは、それらを操作するコードとともにビジネス レイヤーに保持されます。データ層には、永続化フレームワークのデータ モデルと、そのフレームワークと対話するコードの両方が含まれます。これが、クラスの提案された場所と、コメントに基づくそれに対する反応との間の混乱の原因である可能性があると思います.
その観点からすると、取得または取得するものはすべて、必然的にデータ層に配置されます。つまり、永続ストレージ内のデータにアクセスしています。取得したものは、最終的にビジネス ロジックが動作するビジネス レイヤー オブジェクトに変換されます。ものは、注文表のような概念モデルであるか、またはビジネス アクションがビジネス レイヤーに属します。おそらく、(3) が実際に何であるかに応じてどこに行くかについて同じ混乱がある @Adron に同意します。
すなわち：
[編集] (単純な) Web アプリの一般化された 3 層アーキテクチャ
データ アクセス層
これには、TableAdapter と、厳密に型指定された DataTable および Factory が含まれます。これらは、LINQ 以前のプロジェクトで DataTable の行をビジネス オブジェクトに変換します。LINQ を使用すると、これには DataContext とデザイナーが生成した LINQ エンティティが含まれます。
ビジネスレイヤー
これには、検証やセキュリティなど、あらゆるビジネス ロジックが含まれます。LINQ 以前では、これらはビジネス オブジェクトと、アプリケーションのロジックを実装するその他のクラスでした。LINQ を使用すると、これらはビジネス ロジックを実装するための他のクラスと共にセキュリティと検証を実装するための LINQ エンティティの部分クラス実装です。
プレゼンテーション
これらは私の Web フォームです。基本的にはアプリの UI です。検証ロジックの一部を最適化としてフォームに含めていますが、これらは BL でも検証されています。これには、ユーザー コントロールも含まれます。
注:これは論理構造です。プロジェクト構造は一般的にこれを反映していますが、Web サービスへの接続のように、論理的にはコンポーネントが実際には BL/DAL に含まれていても、Web プロジェクトに直接含まれる場合があります。
注: ASP.NET MVC が運用されたら、おそらく MVC over 3-Tier に移行する予定です。Ruby/Rails でいくつかの個人的なプロジェクトを行ったことがありますが、Web アプリの MVC パラダイムがとても気に入っています。
App.Data には、データ構造とインターフェイスのみを含め、実装コードは含めないように指定しました。これを行う場合は問題ありませんが、App.BusinessLogic アセンブリ以外にデータベース アクセス コードを配置する場所がありません。
おそらく、App.Data の名前を App.Model (または同様のもの) に変更し、データベースと対話する新しい App.DataAccess アセンブリを作成する必要があります (おそらく、リポジトリ パターンを実装します)。それを行った後、私は次のように物事を分割します：
私はおそらく一緒に行くだろう