私はジュニア.NETプログラマーです。少数のユーザー（約8人）のために、ローカル環境で販売、顧客、プロバイダー（他にも非常に多くのものがあります）を処理するアプリケーションを開発する必要があります。一元化されたデータベースを使用して、ローカルで使用するためにすべてを作成する必要があります。私のアーキテクチャは上から下に次のようになります。
1.WindowsフォームのUI。
2.ユーザーリクエストを処理するためのコントローラー
3.EntityFrameworkで生成されたオブジェクトであるBussinesオブジェクト
4.SQLデータベース。
明らかに、それがアーキテクチャにとって最善のアプローチではないことはすでに知っていますが、それでも可能な限りシンプルに保ちたいと思います。私はたくさんの研究をしましたが、質問の数が増えているように思われるので、私はこの特定の問題についてのガイダンスを探していました。この質問をuberaskingして申し訳ありませんが、私はオプションに圧倒されています。
初心者を助けるためのTnx。
あなたが説明したことは、ジュニア開発者レベルから来る良いアプローチのようです。
プロジェクトに適したアーキテクチャに影響を与える要因はたくさんあります。時間、スケジュール、お金、単純さまたは複雑さ、保守性、および1回限りのアプリケーションに対する将来の開発拡張。データモデルや未知のシステムとの統合のために、将来のバージョンではとにかく大規模な書き直しが必要になる可能性がありますか？
最初の反復の後、完璧なアプリケーションはありません。優れた開発者なら誰でも、プロジェクトが終了した後、技術的なスキルと知識が増えるにつれて、プロジェクトを改善するための無数の方法を見つけるでしょう。
そうは言っても、データベースとエンティティフレームワークの側面はまったく問題ありません。EFを使用すると、インフラストラクチャではなく機能にすばやく集中できます。EFを他のオブジェクトモデルスイート、または従来のストアドプロシージャベースのアプローチと比較検討したことがあるかもしれません。
UIは、おそらくクライアントまたはビジネスニーズによって決定されます。ここでの他の唯一の大きな決定は、おそらくイントラネットWebアプリケーションであるため、ユーザーのマシンにソフトウェアをインストールすることを心配する必要はありません。
コントローラー/クラスライブラリ/ビジネスレイヤーは理にかなっているため、WinFormsコードでEFに対するクエリを直接記述する必要はありません。これにより、UIをより簡単に取り除いて、将来的に別のものに置き換えることができます。
あなたが概説したものは、正確な状況を知らずに危険信号を投げかけることはありません。そのアプローチを進めて、それがどのように進むかを見てください。完了したら、アーキテクチャのどの側面を処理するのが困難であるか、冗長であるか、またはその他の面倒であるかを考えてください。
Entity Frameworkオブジェクトが生成されると述べたように、ControllerオブジェクトとEntityオブジェクトの間に1つ以上のモデルレベルが必要になる場合があります。特定のビューに複数のエンティティからのデータが含まれていることがよくあります。コントローラがアクセスできる別のレベルのモデルがない場合、一般的に発生するのは、ビジネスロジックがコントローラに移行することです。
言い換えると、コントローラーはモデルを作成し、モデルはエンティティとの対話方法を知っています。
＃2でコントローラーを参照しているので、MVCパターンを使用していると想定していることに注意してください。