問題タブ [namespace-organisation]

私は、インターネットに公的に直面するWebサービスアプリケーションを開発していません。スキーマ定義を幅広い対象者に公開する問題を検討し始めると、スキーマ名前空間を適切にフォーマットするためにある程度の考慮を払う必要があると思います。

組織のXMLスキーマの名前空間形式を標準化する方法をアドバイスするガイドライン文書に出くわした人はいますか？

FQDNとパスの使用などhttp://schemas.organisation.com/とhttp://organisation.com/schemas

バージョンパスを含めるスタイルhttp://organisation.com/schemas/submissions/2006またはhttp://organisation.com/schemas/submissions/v1

日付または主題別の組織http://organisation.com/schemas/2006/submissions/vshttp://organisation.com/schemas/submissions/2006

etcetera

2010年1月12日更新：この問題をもう一度見直すと、実際に書かれた論文があるとしても、これについて正しい答えはあり得ないので、それはwikiである必要があると思います。

SO コミュニティがオフィスでの議論の解決に役立つことを願っています。現時点での結論は「場合による」です。

MVC では、名前空間をどのように編成しますか?

オプション A

モデル、コントローラー、およびビューの名前空間を持つという MS ASP.NET MVC ルートをたどりますか?

オプション B

または、各 MVC トライアドを論理的な「関数」に分割しますか。たとえば、次のようになります。

特徴A

• FeatureAモデル
• FeatureAController
• 種類
  • IFeatureAView (インターフェイス - コントローラーが具体的なビューを参照しないようにするため)
• 意見
  • FeatureAView (コンクリート)

両方のポイントを見ることができます。スタジオでのプロジェクトをより適切に構成するため、オプション B が気に入っています。フィーチャーごとにグループ化されているため、すべてがどこにあるかが一目でわかります。ただし、オプション A は、たとえば、将来すべてのモデルをサービス レイヤーに移動したい場合に、より簡単なスケーリング オプションを提供します。

すべての考えを歓迎します！

例外クラスの場所を構造化するための一般的な、またはベスト プラクティスは何ですか?

パッケージ/名前空間myproject.person(個人用のモデルと DAO) とmyproject.order(注文用のモデルと DAO) と例外PersonExceptionとがあるとしOrderExceptionます。対応するパッケージに例外を配置する必要がありますか、それとも例外用の別のパッケージ (例: myproject.exceptions) に配置する必要がありますか?

最初のアプローチはより合理的です (機能によってソートされているため)。しかし、両方に関連する例外をどこに置くべきかという疑問が生じますか? 例えばConstraintViolationException

たとえば、履歴書を解析するための 2 つのクラスがあり、1 つは Excel を解析し、もう 1 つは HTML を解析します。私の同僚が好んで行うのは、これら 2 つのクラスに同じ名前を付けて、以下に示すように異なる名前空間に配置することです。

クラスの名前を変更し、それらを 1 つの名前空間に配置することをお勧めします (ただし、必要に応じて別のファイルに配置します)。

したがって、階層はまだフォルダーに存在しますが、名前空間は同じです (フォルダー階層と正確に一致しません)。それでよろしいですか?

私が正しければ、同僚を説得する方法はありますか? または、ソリューションに重大な欠点はありますか?

ありがとう。

最近、中規模のアプリケーションをリファクタリングしました。仕事の1つは、一般的に使用されるコードをさまざまなプロジェクトに分割することでした。

さて、一般的に使用される名前空間構造は

Core.Interfaces-のインターフェイスを持つメインアプリケーションの場合IFoo

そして、それぞれの特殊な/外部の/参照されたアセンブリについて、私はそれを拡張することにしました。

Core.Interfaces.Html のインターフェースでIBar

メインアプリケーションのCoreアセンブリはCore、デフォルトの名前空間で名前が付けられたプロジェクトにありますCoreが、HtmlアセンブリHtmlCoreでは、デフォルトの名前空間で名前が付けられたプロジェクトを作成しましたCore。

結果の効果（および私がこの特定の方法論を選択した理由）は、Htmlアセンブリを参照した後は、usingステートメントを更新する必要がなく、正味の効果は次のようになることです。

または上記のusingステートメントを使用して次Core.Interfacesのように変換されます

この暗黙の名前空間構造は依存関係の直接の結果であり、プロジェクトの名前空間の保守がはるかに簡単になり、誰かが持っている必要があるのはアセンブリへの参照だけであるため、実際に役立ちました。構造は、Microsoftが.netフレームワークですでに行っているものと似ています。

問題は、私には考え直しがあり、（将来のプロジェクトのために）次のような各アセンブリに対して明示的な名前空間構造を検討しているということです。

それで、誰かが明示的な構造で作業したことがありますか、両方、または私が試したことのない何か他のものでさえありますか？私は提案を受け入れており、開発中のチームのメンテナンスや混乱から時間を解放することが目標であるため、最善の解決策を探しています。

過去数日間、私は自分が取り組んでいるCLIゲームプロジェクトのファイルをリンクする方法を見つけようとしてきました。プロジェクトには、クライアントコードとサーバーコードの2つの部分があります。

クライアントには、私が作成した2つのライブラリが必要です。1つ目は汎用ゲームボードです。これは、GameEngine.hとGameEngine.cppの間で分割されます。ヘッダーファイルは次のようになります

そして、CPPファイルはすべてのコンテンツを提供しているだけです

クライアントには、宣言と定義（TTT.h、Client.cpp）に分割されたゲーム固有のコード（この場合はTicTacToe）もあります。TTT.hは基本的に

これを名前空間に入れて、クラスではなくグループ化することにしました。これは、OOPでうまく機能しない部分がいくつかあり、後で実装する方がはるかに簡単だからです。

過去にクライアントのリンクに問題がありましたが、この設定は機能しているようです。

私のサーバーもServer.hとServer.cppの2つのファイルに分割されています。

Server.hには正確に次のものが含まれています。

そして、CPPファイルにServer.hを含め、main（）と以前に宣言されたすべての関数の内容を提供します。

今、目の前の問題に 、サーバーをリンクするときに問題が発生しています。具体的には、nsTicTacToe（および場合によってはgfdGaming）のすべての変数で重複シンボルエラーが発生します。TicTacToe関数が必要なので、サーバーを構築するときにClient.cpp（main（）なし）をリンクします

基本的に、これらのエラーを修正するためにコードをより適切に整理する方法についてのアドバイスを探しています。

免責事項：- 初めての投稿であるため、提供した情報が多すぎたり少なすぎたりした場合は、事前にお詫び申し上げます。

-私はこれらの問題を修正するためにstaticとexternを使用しようとしましたが、どうやらそれらは私が必要とするものではありません

このすべてを読んで応答するために時間を割いてくださった方に感謝します=）

Is there a way to 'fake' header files in C# using namespaces? From what I've heard, there is no way to get the preprocessing that they provided in C++; but I'd like the organization aspect of it rather than wrapping classes in namespaces and relying on an IDE to tell me whats in what.

for example (note the incorrect syntax) suppose

where ns1.cs 's contents are:

私のページから YUI3 に JavaScript コードを移植したいと思います。ここにある多くの投稿 (質問と回答) と、YUI3 ページとチュートリアルの多くの情報を読んだ後、スクリプトを動的にロードできるため、コードをモジュールに分割するのが最善の方法であるという結論に達しました。必要なときだけ。

コードをさまざまなサブモジュールにまとめて、コア モジュールによって (必要に応じて) ロードおよび管理したいと考えています。

それらを動的にロードする方法を理解したと思いますが、現在の問題は、モジュール内とモジュール間でパブリックメソッドを常に呼び出すことができないことです。うまくいくこともありますが、メッセージが表示されることもありますxxx is not a function。

MyAppおそらく問題は、グローバル名前空間 (たとえば) を設定し、その名前空間内で「再生」する方法がわからないことです。

次の方法でメソッドを呼び出せるようにしたいと思います: MyApp.Tabs.detectTabs()... メイン モジュール ( MyApp.Core) と同じサブモジュール ( ) の両方のメソッドからMyApp.Tabs。

これが私のコードの構造です：

インライン JavaScript:

モジュール: コア
ファイル: http://www.myapp.com/scripts/Core.js

サブモジュール: タブ
ファイル: http://www.myapp.com/scripts/Tabs.js

グローバル変数、ネームスペースはどこで定義すればよいですか? 関数をどのように呼び出す必要がありますか?

前もって感謝します！

-- オリオール --

現在、プロジェクトがあり、そのサイズは毎日増加しています。私が提供しているAPIのコンテナです。

私は現在、すべてのクラスとすべてのインターフェースをルートに持っています。

Enums、Contants などを独自のフォルダーに分離しましたが、名前空間の一部としてフォルダーを継承しません。それらは、それらを整理するための単なるコンテナーです。

誰かがここで経験を持っているかどうか疑問に思っていましたか？

インターフェイスも独自のフォルダーに分離する必要があります (名前空間の一部としてフォルダーを継承しないでください)

クラスも分けるべきですか？

他のクラスの子であるクラスもあります..つまり、クラスはそれをプロパティとして実装します。したがって、外部でインスタンス化されることはありません。したがって、それらをさらに分離して、(たとえば)「Products」というフォルダーを配置する必要があります。このフォルダー内に、Product クラス、次に item クラス、および Product に固有の他のクラスを配置しますか?

繰り返しますが、名前空間の一部としてフォルダー名を分離し、継承しない手段としてフォルダーを使用します。

フィードバックをお待ちしております。

ありがとう

プロジェクトで名前空間を定義するより良い方法を知りたいです。2 つの異なる winform プロジェクトがあり、両方のプロジェクトで使用する特定のコード ファイルとフォームがあります。したがって、プロジェクト 1 と 2 の構造は以下のとおりです。

したがって、ここでは、クラス C1 (名前空間 common_fun の下) は、両方のプロジェクトで使用される共有ファイルです。ただし、クラス C2 のメソッド M2 を呼び出す必要があり、そのメソッドを呼び出すには、条件付きの using ステートメントを一番上に記述する必要があります。すなわち

だから私の質問は、共通ファイルの名前空間を含めるためのより良い方法はありますか? 将来的には、同じクラス/フォームを使用する 3 ～ 4 個のプロジェクトが存在する可能性があります。

ありがとう。