N 層ソリューションを使用する消極的な理由はありますか?

Question

私は会社に入社してまだ 2 週間ですが、DotNetNuke の .NET 3.5 Team Foundation を使用してシステムの新しいプラットフォームを立ち上げています。私たちの「アーキテクト」は、1 つのクラスのプロジェクトを使用することを提案しています。もちろん、私は「3 層」アーキテクチャ (ビジネス、データ、Web クラス プロジェクト) に応じます。

このアーキテクチャを使用することにデメリットはありますか?プロは、コードをデータから分離すること、クラス オブジェクトをコードから遠ざけることなどです。

Answer 1

かなり大きな欠点は、長期間にわたって作成、管理、保守しなければならないコードの量が増えることだと思います。 小さい プロジェクトはやりすぎかもしれません。

すべては、プロジェクトの規模、最終プロジェクトの予想寿命、予算に応じて何が適切かによって決まります。物事を「適切に」行うことは魅力的ですが、もう少し「軽量」に行うことが商業的に正しい決定となる場合があります。

Answer 2

経験の浅いチームが 3 層を構築するには時間がかかる傾向があります。コードが多くなり、バグも増えます。ただし、私は悪魔の代弁者を演じているだけです。

Answer 3

たとえそれが小規模なプロジェクトであっても、私は N 段階のアプローチを熱心に推し進めます。codesmith + nettiers などの ORM ツールを使用すると、プロジェクトを迅速にセットアップし、ビジネス上の問題を迅速に解決するコードを開発できるようになります。

新しいプロジェクトを開始し、糸車の周りに座って「アーキテクチャ」をどのように構築するかを話し合って何日も過ごすと、本当に疲れます。あなたは、他の人が解決してくれた問題を解決するのではなく、ビジネス上の問題を解決することに時間を費やしたいと考えています。最初の推進力を得るために ORM (実際にはどれかは重要ではありません。1 つを選択してそれに固執するだけです) を使用すると、プロジェクトの目標に集中し続けることができ、「アーキテクチャ」の問題の解決に気を散らすことがなくなります。

結局のところ、アーキテクトが 1 つのプロジェクトのアプローチを採用したい場合は、BLL フォルダーと DAL フォルダーを含む app_code フォルダーを作成して、現時点ではコードを分離できない理由はありません。これにより、プロジェクトへの移行が容易になります。 N 層ソリューションについては後で説明します。

Answer 4

あなたが欲しいから 能力 レイヤーを異なる物理層に分散できるようにするには (私は常に物理には「層」、論理には「レイヤー」を使用します)、すべてを 1 つのクラスにまとめる前によく考えてください。大規模なリファクタリングが必要になるためです。または配布を開始する必要がある場合。

Answer 5

他のものと同様、抽象化は複雑さを生み出すため、N 層化の複雑さは適切に正当化される必要があります。たとえば、N 層化は実際にシステムに利益をもたらしますか?そこには 意思 N 層で最適に動作する小規模システムである必要がありますが、多くのシステムはそうではありません。

また、現時点ではシステムが小規模であっても、後でさらに機能を追加することもできます (N 層化するわけではありません)。 かもしれない ある種の技術的負債が発生するため、注意が必要です。

Answer 6

唯一の欠点は複雑さですが、実際には、データセットを使用するのとは対照的に、いくつかのドメイン オブジェクトを追加してそれらのリストにバインドするのがどれほど難しいかです。3 つの別々のプロジェクトを作成する必要さえありません。Web アプリ内に 3 つの別々のフォルダーを作成し、それぞれに YourCompany.YourApp.Domain、YourCompany.YourApp.Data などの名前空間を与えるだけです。

大きな利点は、より柔軟なソリューションがあることです。アプリをデータ中心のアプリケーションとして作成し始め、Web フォーム ページをデータセットに強力に結合すると、ビジネス ロジックが複雑になるにつれて、後でよりドメイン中心のモデルに移行するために、より多くの作業を行うことになります。

おそらく短期的には、非常に単純なドメイン オブジェクトを作成し、データセットからそれらを設定するという単純なソリューションに焦点を当て、その後、必要に応じてビジネス ロジックを追加し、必要に応じてより洗練された ORM を構築したり、nhibernate を使用したりすることができます。