名前空間/ソリューション構造
https://stackoverflow.com/questions/12243
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
このような一般的な質問をして申し訳ありませんが、それは私にとって難しいことがわかります。私のチームは、何年にもわたって進化してきたランダムな 1 回限りのコードベースをすべて統合する大規模なプロジェクトに着手しようとしています。このプロジェクトでは、会社全体の論理エンティティ (「顧客」、「従業員」)、小さなタスク、小さなタスクを制御する大きなタスク、およびユーティリティ サービスの標準化をカバーすることを考えると、名前空間とコード構造。
詳細を十分に説明できていないように思いますが、 ドメインを論理的に分割する方法に関するリソースやアドバイスはありますか?役立つ場合に備えて、この機能のほとんどは Web サービス経由で公開されます。 マイクロソフト 最新のギズモやガジェットをすべて取り揃えたショッピング。
- 参照を容易にするために、サブプロジェクトを使用した大規模なソリューションについて議論していますが、それでは扱いにくくなりますか?
- レガシー アプリケーションの機能をまとめるべきか、それとも名前空間に完全に依存しないままにしておくべきか (
OurCRMProduct.CustomerクラスとジェネリックCustomerたとえばクラス）? - 各サービス/プロジェクトに独自のものが必要か
BALそしてDAL, 、それともすべてが参照する完全に別個のアセンブリにする必要がありますか?
私にはそのような広範囲にわたるプロジェクトを企画した経験がなく、一回限りのことしかないので、何かアドバイスが得られるか探しています。
解決
猫の皮を剥ぐ方法は何百万通りもある。ただし、最もシンプルなものが常に最良です。あなたにとって最も簡単な方法はどれですか?要件に応じて異なります。しかし、私が従う一般的な経験則がいくつかあります。
まず、プロジェクト全体の数を可能な限り減らします。1 日に 20 回コンパイルすると、その余分な 1 分が加算されます。
アプリが拡張性を考慮して設計されている場合は、設計と拡張性の線に沿ってアセンブリを分割することを検討してください。実装。インターフェイスと基本クラスをパブリック アセンブリに配置します。これらのクラスの会社の実装用のアセンブリを作成します。
大規模なアプリケーションの場合は、UI ロジックとビジネス ロジックを分離してください。
ソリューションを簡素化します。複雑すぎるように見える場合は、おそらく複雑です。組み合わせる、減らす。
他のヒント
同様の取り組みに着手した私からのアドバイスは、名前空間について悩まないことです。
いくつかの重要で緩やかなガイドラインに従って開発を始めてください。どのように始めても、プロジェクトは有機的であり、 意思 最終的には、時間の経過とともに名前空間とクラスが再編成されます。
プロジェクトについて話しすぎて時間を無駄にしないでください。やるだけ。
私も最近仕事で全く同じことを経験しました。構造化して整理する必要がある大量のアドホック コード。
量が多いので最初は本当に大変です。私ができる最善のアドバイスは、 それに時間を投資する 金曜日の午後の気の緩んだところで、数週間の間、私はただアプリやコードの塊を選び、そこにあるものを調べ、何をジェネリックにできるかを考え、それをコピーし、思いついた場所に新しいライブラリに入れました。そのはず。アプリケーション内のすべてのコードを移行したら、次に、共通フレームワークで動作するようにアプリケーションをリファクタリングします。これにより、修正が必要な問題が発生することがありましたが、徹底的に対処していれば、それほど大きな問題にはならないはずです。
少しずつ、それが唯一の方法です。
構造に関しては、ほとんどの部分が非常に論理的であるため、MS 名前空間を模倣しようとしました (例: 会社.データ , 会社.Web , 会社.Web.UI 等々。
主な利点の 1 つは、おそらく、コードの重複が削除される量です。はい、アプリでは少しリファクタリングが必要でしたが、コードベースははるかに無駄がなく、多くの点で「スマート」になりました。
もう 1 つ気づいたことは、理解しようとすると問題が発生することがよくあるということです。 どこ それが何に属しているか分からなかったので、（名前空間の観点から）何かを置くためです。さて、これ 本当に 私はそれをとても嫌な臭いだと思っていました。再編成以来、すべてがよりうまく空間に収まるようになりました。そして、(現在は非常に少量の) アプリケーション固有のコードを使用すると、 Company.Applications.ApplicationName これは、この名前空間内にあまり多くのことを望んでいないので、ビジネス オブジェクトについてより深く考えるのに役立ち、より柔軟な設計を思いつくことができます。
長文ですみません..なんだかとりとめのない話ですね！
.NET では、次のようにアセンブリに Company.Project.XXXX.YYYY という名前を付けます。ここで、XXXX はプロジェクト、YYYYY はサブプロジェクトです。たとえば、次のようになります。
- LCP.AdmCom.Common
- LCP.AdmCom.BusinessObjects
- LCP.AdmCom.Common.Dal
これはブックコールから抜粋したものです フレームワーク設計ガイドライン Krzysztof Cwalina (著), Brad Abrams (著)
大規模なプロジェクトの場合、私が好んで採用するアプローチは、ビジネス オブジェクト用に 1 つのドメイン名前空間を用意し、ビジネス オブジェクトの保存と取得が必要なレイヤーでデータ転送オブジェクト (DTO) を使用することです。DTO は、ビジネス ロジックを含まない単純なオブジェクトです。
DTO について説明するリンクは次のとおりです。
多くのプロジェクトを含む大規模なソリューションはコンパイルに時間がかかることがありますが、まとめて管理するのは簡単です。
単体テスト アセンブリをテスト対象のアセンブリと同じソリューションに含めることがよくあります。これは、単体テスト アセンブリを一緒に変更する傾向があるためです。
