.net - 小規模な（っぽい）アプリケーションに3層アーキテクチャを使用する価値はありますか

Question

私は比較的小さなasp.netWebアプリケーションに取り組んでおり、完全なn層アーキテクチャを採用する必要があるかどうか疑問に思っています。サイズのアイデアについては; 約20のデータベーステーブルがあります。

以前は、ビジネスロジックとデータアクセスを1つのクラスライブラリにグループ化する2層アプローチを使用し、UI層を形成するasp.net Webアプリケーションを使用しましたが、これは問題なく機能するようでした。

n層を採用する必要があるしきい値サイズまたは経験則はありますか？

Answer 1

今は比較的小さいかもしれませんが、将来は成長すると思いますか？もちろん、実用的である必要がありますが、単一のアセンブリ内ですでに関心の分離が自然にある場合は、それを2つ以上のアセンブリに分割するのはかなり簡単です。クラス自体がビジネスロジックとデータアクセスを組み合わせている場合は、より多くの作業が必要になります。ただし、最初にすべてを1つの場所に書き込むよりも、一方のアセンブリにデータアクセスロジックを記述し、もう一方のアセンブリにビジネスロジックを並列に書き込むことは、ほとんど作業ではないと思います。

Answer 2

何らかの成長や変化が予想される場合は、今すぐ明示的な階層を強化することをお勧めします。しかし、これがあなた自身のプロジェクトであり、変更や緊密に統合されたコードのコストを負担することを気にしないのであれば、1つのレイヤーのようにそれをハックしてください。

将来のコストがすべてです。現在のところ、プログラミングをそのまま行うのがはるかに安価ですが、変化にうまく対応することはできません。階層計画では、初期費用がかかりますが、最初のアプローチよりも変更を処理し、レイヤー全体の実装を適切に取り除くことができます。

したがって、経験則は、変更の支払いを誰がいつ行うかによって決まります。

Answer 3

はい、それだけの価値があります。あなたが提案しているのは、ソリューションを一緒にハッキングすることです。これが私に何回痛みと苦しみをもたらしたかわかりません。そのコインの反対側は、ソリューションを過剰に構築する天文学的な開発者です。これも避けたいところです。

シンプルに、3 つのレイヤーを構築してください。LINQ to SQL を試してみることをお勧めします。これにより、DAL の構築が簡単になり、スリムな UI と、重労働を処理する BLL の構築に集中できます。それほど時間はかからず、後で単体テストを行うことができます。

Answer 4

n層を採用する必要があるしきい値サイズまたは経験則はありますか？

私が知っているものではありませんが、これを破棄します：このWebアプリが成長する（またはバックエンドを変更する）可能性がある場合、および/または他の誰かがそれを維持する可能性がある場合は、nを使用することを検討します-層アプローチ。

Answer 5

可能な限り維持してください。今はやり過ぎかもしれませんが、それが不可能な状況に自分自身を書き込まないでください。大規模なリファクタリングは、最初から再構築するよりも時間がかかります (おそらく、ゼロから再構築するだけです)。

私が取り組んだ最後のプロジェクト (遅れてやってきた) は、層を分割することが実質的に不可能な方法で書かれていました。データ ロジックとビジネス ロジックが織り交ぜられ、プレゼンテーション ロジックが織り込まれています。短期的には、修正には数か月かかるため、これまでにないほど良好でした。

すべてを分離しておくことはそれほど難しくないので、先ほども言ったように、可能な限り分離してください。