10

このような一般的な質問をしたことをお詫びしますが、それは私にとってやりがいのあることです。私のチームは、何年にもわたって進化してきたランダムな1回限りのコードベースをすべてまとめる大規模なプロジェクトに着手しようとしています。このプロジェクトは、会社全体の論理エンティティ（「顧客」、「従業員」）、小さなタスク、小さなタスクを制御する大きなタスク、およびユーティリティサービスを対象としているため、構造化するための最良の方法を見つけるのに苦労しています。名前空間とコード構造。

先に進むのに十分な詳細を提供していないと思いますが、ドメインを論理的に分割する方法についてのリソースやアドバイスはありますか？役立つ場合は、この機能のほとんどがWebサービスを介して公開されます。私たちは、最新のギズモとガジェットをすべて備えたMicrosoftショップです。

  • 参照を簡単にするためにサブプロジェクトを使用した1つの大規模なソリューションについて議論していますが、それでは扱いにくくなりますか？
  • レガシーアプリケーションの機能をまとめる必要がありますか、それとも名前空間に完全に依存しないままにする必要がありますか（たとえば、OurCRMProduct.Customerクラスとジェネリッククラスの作成）？Customer
  • 各サービス/プロジェクトには独自のBALとDALが必要ですか、それともすべてが参照する完全に別個のアセンブリである必要がありますか？

私はそのような広範囲にわたるプロジェクトを組織した経験がなく、1回限りのことなので、私が得ることができるガイダンスを探しています。

4

6 に答える 6

12

猫の皮を剥ぐ方法は無数にあります。ただし、最も単純なものが常に最適です。あなたにとって最も簡単な方法はどれですか？要件によって異なります。しかし、私が従う一般的な経験則がいくつかあります。

まず、プロジェクトの総数をできるだけ減らします。1日に20回コンパイルすると、その余分な分が加算されます。

アプリが拡張性を考慮して設計されている場合は、アセンブリを設計と実装のラインに沿って分割することを検討してください。インターフェイスと基本クラスをパブリックアセンブリに配置します。これらのクラスの会社の実装用のアセンブリを作成します。

大規模なアプリケーションの場合は、UIロジックとビジネスロジックを分離してください。

ソリューションを簡素化します。複雑すぎるように見える場合は、おそらくそうです。組み合わせる、減らす。

于 2008-08-15T13:39:01.987 に答える
7

同様の取り組みに着手した私のアドバイスは、名前空間に苦しんではいけないということです。

いくつかの重要な大まかなガイドラインから開発を開始してください。どのように始めても、プロジェクトは有機的であり、時間の経過とともに名前空間とクラスを再編成することになります。

プロジェクトについて話しすぎないでください。早くやれよ。

于 2008-08-15T14:01:08.433 に答える
4

私は最近、職場でまったく同じことを経験しました。構造化および整理する必要のある多くのアドホックコード。

たくさんあるので、最初は本当に大変です。私ができる最善のアドバイスは、金曜日の午後の終わりに時間を費やすことです。数週間は、アプリ/コードのチャンクを選び、そこに何があったかを調べ、何ができるかを考えます。ジェネリックにし、それをコピーして、私が思ったところならどこでも新しいライブラリに入れてください。アプリケーション内のすべてのコードを移行したら、共通のフレームワークから機能するようにアプリケーションのリファクタリングに取り組みます。これにより、修正が必要な問題が発生することがありましたが、徹底的に大きくなりすぎないようにする必要があります。取引。

一つ一つ、それがそれをする唯一の方法です。

構造に関しては、MSの名前空間を模倣しようとしました。これは、ほとんどの場合、MSの名前空間がかなり論理的であるためです（たとえば、 Company.Data、Company.Web、Company.Web.UIなど）。

主な利点の1つは、おそらく削除されたコードの重複の量です。ええ、アプリでは少しリファクタリングが必要でしたが、コードベースははるかにスリムで、多くの点で「よりスマート」です。

私が気付いたもう1つのことは、それが何に属しているのかわからなかったため、（名前空間の観点から）どこに物を置くかを理解しようとすると問題が発生することがよくあるということです。今、これは本当に私を心配しました、私はそれをそのような悪臭として見ました。再編成されてから、すべてがよりうまく宇宙に収まるようになりました。そして、（現在は非常に少量の）アプリケーション固有のコードを使用すると、それらはCompany.Applications.ApplicationNameに配置されます。これは、この名前空間内であまり多くを必要としないため、ビジネスオブジェクトについてより多く考えるのに役立ちます。柔軟なデザイン。

長い投稿でごめんなさい..それはちょっととりとめのないです！

于 2008-08-15T13:39:06.730 に答える
4

.NETでアセンブリに次のように名前を付けます。Company.Project.XXXX.YYYYここで、XXXXはプロジェクト、YYYYYはサブプロジェクトです。次に例を示します。

  • LCP.AdmCom.Common
  • LCP.AdmCom.BusinessObjects
  • LCP.AdmCom.Common.Dal

これは、 Krzysztof Cwalina（著者）、Brad Abrams（著者）による「 FrameworkDesignGuidelines」という本から引用したものです。

于 2008-08-15T13:43:38.373 に答える
3

大規模なプロジェクトの場合、私が採用したいアプローチは、ビジネスオブジェクト用に1つのドメイン名前空間を用意し、ビジネスオブジェクトの保存と取得が必要なレイヤーでデータ転送オブジェクト（DTO）を使用することです。DTOは、ビジネスロジックを含まない単純なオブジェクトです。

DTOを説明するリンクは次のとおりです。

http://martinfowler.com/eaaCatalog/dataTransferObject.html

于 2008-08-15T13:46:10.413 に答える
0

プロジェクトが多い大規模なソリューションは、コンパイルにかなり時間がかかる場合がありますが、一緒に管理する方が簡単です。

ユニットテストアセンブリは、一緒に変更する傾向があるため、テストしているものと同じソリューションで使用することがよくあります。

于 2008-08-15T13:40:31.297 に答える