私が働いている会社は最近、今後のすべての開発作業に .NET と Java を組み合わせて使用することを決定しました。私たちは、コードを名前空間 (.NET) とパッケージ (Java) に整理する方法を標準化しようとしてきましたが、複数のプラットフォームを含む複数の製品の名前空間を整理しようとした経験はありません。
最近、Java フロントエンド (Blackberry デバイスで実行) と .NET バックエンド (Java フロントエンドが従来の VB6/COM コードと通信できるようにするメッセージ ブローカー) を使用する新製品に関与しました。 Java 側で COM を処理したい場合、既存の VB6 コードで .NET を簡単に動作させることができます)。現在、私は .NET 側に焦点を当てています。
という名前の新しい .NET ソリューションを作成しCompanyName.ProductName.Broker
、最終的に 2 つのサブプロジェクトができましCore
た。ブローカー コードの大部分を実装するクラス ライブラリ プロジェクトと、BrokerConsole
ブローカーをコマンドラインから開始および停止できるようにするコンソール プロジェクトです (ブローカーは実行されます)。サーバー上で RabbitMQ メッセージ キュー サーバーと一緒に)。
現在、両方のプロジェクトがCompanyName.ProductName.Broker
名前空間のサブ名前空間にあります。問題は、これは理にかなっていますか?
一方では、BrokerConsole
プロジェクトはプロジェクトにかなり緊密に結合されていCore
ますが、他方ではBrokerConsole
、スタンドアロンの EXE にコンパイルされます。BrokerConsole
プロジェクトを別のルート名前空間に配置する方が理にかなっているのではないかと考えていました。CompanyName.Apps.ProductName
これは、実際にはフロントエンドでCompanyName.ProductName.Broker.Core.dll
あり、ライブラリではなくアプリケーションであるためです。
まったく新しいCompanyName.Apps
ルート名前空間を作成する理由は、通常、アプリケーションを作成するときに、参照しているライブラリとは別の名前空間に配置する (つまり、Web サーバー アプリケーションをSystem.Web
名前空間に配置しない) ことです。参照されているライブラリがたまたま会社によって開発されたライブラリであることを除いて、私は同じ方向に沿って考えています。
これは良い考えですか、それとも「製品」(マーケティング用語で) に関連するすべてのものを共通のCompanyName.ProductName
名前空間に保持するように努めるべきですか? 1 つの製品を構成する複数のプロジェクトを管理するためのより良い方法はありますか?