私は会社に入社してまだ 2 週間ですが、DotNetNuke の .NET 3.5 Team Foundation を使用してシステムの新しいプラットフォームを開始しています。私たちの「アーキテクト」は、1 つのクラス プロジェクトを使用することを提案しています。もちろん、私は「3 層」アーキテクチャー (ビジネス、データ、Web クラスのプロジェクト) を考えています。
このアーキテクチャを使用することの欠点はありますか? プロは、コードをデータから分離し、クラスオブジェクトをコードから遠ざけるなどです。
かなり大きなマイナス面は、小さなプロジェクトのために作成、管理、保守しなければならない余分な量のコードが過剰になる可能性があることだと思います。
プロジェクトの規模、最終的なプロジェクトの予想寿命、予算に応じて何が適切かが決まります。物事を「適切に」行うことが魅力的である一方で、もう少し「軽量」なことを行うことが商業的に正しい決定になる場合があります。
経験の浅いチームが 3 層を構築するには時間がかかる傾向があります。コードが増えるため、バグも増えます。私は悪魔の代弁者を演じているだけです。
レイヤーを異なる物理層に分散できる機能が必要なため（私は常に物理層に「層」、論理層に「層」を使用します）、すべてを1つのクラスにまとめる前に、よく考えておく必要があります。配布を開始する必要がある場合、または必要な場合に行う主要なリファクタリング。
たとえそれが小さなプロジェクトであっても、私は N 層のアプローチを強く推し進めます。codesmith + nettiers のような ORM ツールを使用すると、プロジェクトをすばやくセットアップして、ビジネス上の問題をすばやく解決するコードを開発することができます。
新しいプロジェクトを開始し、「アーキテクチャ」がどのように構築されるべきかについて話し合う車輪の周りに座って何日も過ごすとき、それは私を殺します. 他の人が解決した問題を解決するのではなく、ビジネス上の問題を解決することに時間を費やしたいと考えています。最初の牽引力を得るために ORM を使用すること (どれを選んでも問題ありません。1 つを選んでそれに固執するだけです) は、プロジェクトの目標に集中し続けるのに役立ち、「アーキテクチャ」の問題を解決しようとして気を散らすことはありません。
結局のところ、アーキテクトが 1 つのプロジェクト アプローチに移行したい場合、BLL フォルダーと DAL フォルダーを含む app_code フォルダーを作成してコードを分離できない理由はありません。後で N 層ソリューション。
唯一の欠点は複雑さですが、データセットを使用する場合とは対照的に、いくつかのドメイン オブジェクトを追加してそれらのリストにバインドするのは、実際にはどれほど難しいことでしょう。3 つの個別のプロジェクトを作成する必要さえありません。Web アプリ内に 3 つの個別のフォルダーを作成し、それぞれに YourCompany.YourApp.Domain、YourCompany.YourApp.Data などの名前空間を与えるだけです。
大きな利点は、より柔軟なソリューションを持つことです。アプリをデータ中心のアプリケーションとして書き始め、Web フォーム ページをデータセットに強く結合すると、ビジネス ロジックが複雑になるにつれて、後でより多くの作業をドメイン中心のモデルに移行することになります。
短期的には、非常に単純なドメイン オブジェクトを作成してデータセットからデータを取り込むという単純なソリューションに集中し、必要に応じてビジネス ロジックを追加し、必要に応じてより洗練された ORM を構築したり、nhibernate を使用したりできます。
あらゆるものと同様に、抽象化は複雑さを生み出します。したがって、N 層を行う複雑さは適切に正当化されるべきです。たとえば、N 層は実際にシステムに利益をもたらすのでしょうか? N 層で最適に動作する小規模なシステムもありますが、多くはそうではありません。
また、現時点ではシステムが小さい場合でも、後で機能を追加する必要がある場合があります。N 層にしないと、一種の技術的負債が発生する可能性があるため、注意する必要があります。