Winforms C＃ソリューションの構築

Question

そのため、winforms C＃ソリューションを再編成し、分離し、よりクリーンで整理されたものにします。このソリューションは、中小企業の注文などを追跡します。 。

これまでにプロジェクトを分割しました

App.View -すべてのGUI関連コード
App.Data -データ構造とインターフェースのみ。他の実装コードはありません
App.BusinessLogic -GUI参照のないすべてのビジネスロジックコード

いくつかのクラスがあり、それらがどこに属しているのかわかりません。各クラスがどのプロジェクトに行くべきか、またはこのために作成する必要がある別のプロジェクトがあるかどうか、あなたの考えを教えてください。

1. データベースからユーザー設定を取得するクラス
2. 静的データサーバーから静的データを取得し、データ結果のセットを返すクラス。
3. ユーザーの資格をもたらすクラス
4. 注文のハッシュテーブルを格納するモデルクラス
5. ユーザーアクションに関するメッセージをメールで送信するクラス

Answer 1

実際、従来の階層化アーキテクチャとは少し違うものがあると思います。通常、アプリケーションが動作するデータのモデルは、それらを操作するコードとともにビジネスレイヤーに保持されます。データ層には、永続フレームワークのデータモデルと、そのフレームワークとやり取りするコードの両方があります。これは、クラスの提案された場所とコメントに基づいたそれに対するあなたの反応の間の混乱の原因であると思います。

この観点から、取得またはもたらすものはすべてデータレイヤーに必ず配置されます。つまり、永続ストレージのデータにアクセスします。取得したものは、最終的にビジネスロジックが動作するビジネスレイヤーオブジェクトに変換されます。物事は、注文の表のような概念モデルであるか、ビジネス層に属するビジネスアクションです。 @Adronには、おそらく（3）が実際に何であるかに応じてどこに行くのかについて同じ混乱があることに同意します。

より具体的に：

1. ユーザー設定はビジネスです オブジェクト、取得するもの それらはデータレイヤーオブジェクトです。
2. 静的データはビジネスにマッピングされます オブジェクト（テーブルまたはビューまたは何か）、 外部にアクセスするもの サーバーはデータレイヤーオブジェクトです。
3. ユーザーの資格はビジネスオブジェクトであり、それを取得するのはデータレイヤーオブジェクトです。
4. 注文の表はビジネスオブジェクトです
5. 電子メールはビジネスアクティビティなので、人々にメールを送ることはビジネスオブジェクトです

[編集]一般的な3層アーキテクチャ（単純な）Webアプリ用

DataAccessLayer

これには、TableAdaptersと、DataTableの行をLINQ以前のプロジェクトのビジネスオブジェクトに変換する厳密に型指定されたDataTableとファクトリが含まれます。 LINQを使用すると、これにはDataContextとデザイナーが生成したLINQエンティティが含まれます。

BusinessLayer

これには、検証やセキュリティなどのビジネスロジックが含まれます。 LINQ以前では、これらは私のビジネスオブジェクトと、アプリケーションのロジックを実装する他のクラスになります。 LINQを使用するこれらは、ビジネスロジックを実装する他のクラスとともにセキュリティと検証を実装するためのLINQエンティティの部分クラス実装です。

プレゼンテーション

これらは私のWebフォームです。基本的にはアプリのUIです。最適化としてフォームに検証ロジックの一部を含めますが、これらはBLでも検証されます。これには、ユーザーコントロールも含まれます。

注：これは論理構造です。通常、プロジェクト構造はこれを反映しますが、Webサービスへの接続など、論理的にはコンポーネントが実際にはBL / DALにあるにもかかわらず、Webプロジェクトに直接含まれる場合があります。

注： ASP.NET MVCの運用が開始されたら、おそらく3層以上のMVCに移行するでしょう。 Ruby / Railsで個人的なプロジェクトをいくつか行ったことがありますが、WebアプリのMVCパラダイムが本当に好きです。

Answer 2

App.Dataにはデータ構造とインターフェイスのみを含め、実装コードは含めないように指定しました。これは必要な場合は問題ありませんが、App.BusinessLogic以外にデータベースアクセスコードを配置する場所はありませんアセンブリ。

おそらく、本当にApp.Dataの名前をApp.Model（または同様のもの）に変更し、データベースと通信する新しいApp.DataAccessアセンブリが必要になる（おそらくリポジトリパターンを実装する）必要があります。それが終わったら、次のように分割します：

1. App.DataAccess
2. App.DataAccess
3. App.DataAccess
4. App.Model
5. App.BusinessLogic

Answer 3

おそらく一緒に行きます

1. データ
2. データ
3. データ、クラスが何をしているかは完全にはわかりませんが
4. データ
5. BusinessLogic

Answer 4

1. -＆gt; App.Data
2. -＆gt; App.Data
3. -＆gt; App.BusinessLogicまたはApp.Data-これが何を意味するのか正確にはわかりません。
4. -＆gt; App.BusinessLogic
5. -＆gt; App.BusinessLogic