タグ付けされた質問 「c#」

私は最近Unity3Dを使い始め、主にC＃でスクリプトを書き始めました。私は通常Javaでプログラミングしているので、違いはそれほど大きくありませんが、正しいコースにいることを確認するためにクラッシュコースを参照しました。 ただし、C＃に対する私の最大の好奇心は、メソッド名の最初の文字を大文字にすることです（たとえば、Java：getPrime()C＃：GetPrime()aka：Pascal Case？）。これには正当な理由がありますか？私はクラッシュコースのページから、明らかに。たとえば、Javaが使用します。 注：言語には独自のコーディング規約があることは理解していますが（Pythonの方法はすべて小文字で、この質問にも当てはまります）、なぜ標準に正式化されないのか理解できませんでした。

14 c#  coding-standards 

私は週末にいくつかのコードを書いていましたが、ファクトリを基本クラスの静的メソッドとして書きたいと思いました。 私の質問は、これが独創的なアプローチであるかどうかを知ることですか？ 基本クラスが派生クラスの知識を持っているという事実からではないかもしれないという私の感覚です。 そうは言っても、同じ結果を得るためのもっと簡単な方法はわかりません。他のファクトリクラス全体は（少なくとも私には）不要な複雑さ（？） 何かのようなもの： class Animal { public static Animal CreateAnimal(string name) { switch(name) { case "Shark": return new SeaAnimal(); break; case "Dog": return new LandAnimal(); break; default: throw new Exception("unknown animal"); } } } class LandAnimal : Animal { } class SeaAnimal : Animal { }

14 c#  class-design 

私は最近、C＃の動的型についてさらに研究しています。コードをコンパイルすると理解できる例がいくつかありますが、コードを再コンパイルする必要はありませんが、直接実行できます。 実際にデータ型を自由に変更できるというキーワードが提供する柔軟性は大きな利点であると感じています。 質問、 開発者が実装を開始する前に知っておく必要がある実行時例外をスローする間違った動的メソッド呼び出し以外に、特定の欠点がありますか。

14 c#  .net  visual-studio-2010 

Zeroc-ICEで実行されるサーバーコンポーネントがあります。ロードテストをしたいとき、並列ライブラリを使用して複数の要求を作成すると思いました。しかし、それはそのようになってしまいます。C＃のParallel（Parallel.For）ライブラリを使用する方が簡単なようですが、すべてを同じ瞬間に正確に生成しているようには見えません。したがって、1秒あたりN個の要求を作成するための定義にはなりません。どうすればいいですか？最初に負荷テストをしたい人はだれでも実際にこれについて考えると思います。 実際に1秒あたりN個のリクエストを実際に作成する効率的な方法は何ですか？ もう1つの神話は、並列プログラミングに関するものです。一般的にC＃または.Netで並列プログラミングパターンを使用している場合は、ご理解ください。5つのプロセスがあるとします。5つのプロセスすべてを同時に開始する方法。リソースを消費することはどういう意味ですか？私はネット上で入手可能な多くの資料を読んでみましたが、質問に対する答えよりも多くの質問があります。 Parallel.Forを使用して、N個のスレッドを作成し、時間を測定しました。次に、タスクの列挙にTask.Factory.startを使用して同じことを試みました。測定された時間は異なっていました。それで、これらを使用することの正確な違いは何ですか？対応するクラスをいつ使用し、どのような目的のために正確に使用する必要がありますか？私たちは多くの富を持っていることが多いのですが、それをどうやって区別するのか正確にはわかりません。これは私にとってそのようなケースの1つであり、なぜ別のものを使用すべきではないのかを見つけることができません。 私はストップウォッチクラスを使用して、これらの時間を測定しました。私のシナリオでは、コンポーネントの負荷テストで、応答時間を測定する方法は何でしょうか。ストップウォッチは私にとって最良の解決策のようです。ご意見をお待ちしています。 ps：Webアプリケーション用の負荷テストツールは多数あります。私のものは、サーバーコンポーネントのカスタマイズされたケースです。私の質問は、1秒あたりN個のスレッドの作成に関するものです。 すべての意見を歓迎します。プログラミングの問題ではないと考えないでください。もちろんです。自分で製品の品質を知りたいプログラマーが自分で製品のパフォーマンスを知りたい場合は、ベルを鳴らさなければなりません。

14 c#  server  load-testing 

List.ForEach(Console.WriteLine); List.ForEach(s => Console.WriteLine(s)); 私にとって、違いは純粋に化粧品ですが、一方が他方よりも好まれる微妙な理由はありますか？

14 c#  syntax  lambda 

Fortan77プログラムをC＃に変換しようとしています。約650行のコードと恐ろしいGOTOステートメントを含むサブルーチンが至る所にあります。サブルーチンのフローを視覚化して、それが何をするのかを理解し始めることさえ、私は多くの問題を抱えています。 この種の経験があり、このサブルーチンの概要を取得する方法についてアドバイスしてくれる人はいますか？このタイプの変換を高速化または促進するために使用できるツールはありますか？

14 c#  fortran 

最近、仕事で同僚の何人かと議論しました。彼らは、.DLLに暗号化された文字列接続がある方が良いと言ったからです。そして、web.configで暗号化された文字列接続を暗号化しないのはなぜだと言いましたか？エンティティフレームワークは、たとえば、アプリケーションのWeb構成で接続の名前を検索するため、同じであり、より優れています。セキュリティポイントから、何がベストか、何がベストプラクティスかを知りたいですか？

14 web-development  c#  asp.net  security  entity-framework 

C＃プロジェクトのクラス階層を設計する必要があります。基本的に、クラスの機能はWinFormsクラスに似ているため、WinFormsツールキットを例に取りましょう。（ただし、WinFormsやWPFは使用できません。） すべてのクラスが提供する必要があるいくつかのコアプロパティと機能があります。寸法、位置、色、可視性（true / false）、Drawメソッドなど。 設計上のアドバイスが必要です。抽象ベースクラスと実際には型ではなく、動作に似たインターフェイスを持つ設計を使用しました。これは良いデザインですか？そうでない場合、より良いデザインになります。 コードは次のようになります。 abstract class Control { public int Width { get; set; } public int Height { get; set; } public int BackColor { get; set; } public int X { get; set; } public int Y { get; set; } public int BorderWidth { get; …

14 c#  object-oriented  design-patterns  class-design 

.NETイベントモデルの理解にかなり満足しています。システムの小さなニュアンスを誤解しているのではないかと思います。 クラスにイベントを入れ始めたとき、次のような標準的な方法を使用します。 public event EventHandler<MyEventArgs> MyEvent; これは、イベントにサブスクライブするものには、次のようなメソッドが必要であることを意味しました。 void HandleThatEvent(object sender, MyEventArgs args){...} これは素晴らしいことですが、送信者を気にすることはめったにないため、多くのメソッドシグネチャが肥大化しました。 だから私は自分のデリゲート型の宣言に切り替えました public delegate void MyEventHandler(SomeClass argument); これにより混乱が減りましたが、ハンドラーの作成に関して小さな問題が残りました。 eventImplmentor.MyEvent += HandleThatEvent; . . . void HandleThatEvent(/*oh, um, what arguments does it take? Intellisense isn't telling me*/) だから私はデリゲートの宣言に戻って見て、そして戻ってそれらを書くか、それをコンパイルして言われるのを待たなければなりません。 だから今、代わりに、私はちょうどAction、Action<T>または適合するテンプレートを使用しています。 public event Action<SomeClass> MyEvent; イベントにカーソルを合わせて、どのパラメーターが期待されるかを知ることができます。 私の質問、結局のところ：C＃でイベントを宣言するためのベストプラクティスはありますか？EventHandler<T>道に戻る必要がありAction<T>ますか、それとも容認できますか？

14 c# 

同じ名前の変数とフィールドを区別する必要がない限りthis.、C＃でフィールドまたはメンバーアクセスの前に配置することはありません。これはm_、C ++で一般的に使用されていたプレフィックスと同じであり、メンバーであると指定する必要がある場合、クラスが大きすぎると思います。 しかし、私のオフィスには多くの人々が強く反対しています。 現在のベストプラクティスと見なされるものは何this.ですか？ 編集：明確にするために、私は絶対に使用することはm_なくthis.、絶対に必要な場合にのみ使用します。

14 c#  coding-style 

Codeplexでの最初のオープンソースプロジェクトの作業を開始し、いくつかのひどいコードに遭遇しました。（C＃にはまだ「goto」ステートメントがあることを学びました）「所有者」が望んでいた機能を追加し始め、コードベースを調べて、それが何であるかを確認しました（例：「goto」を使用）少し。しかし、私は少し心配しているので、私はあなたにすべてを向けている理由です：私にとって「悪いコード」を「修正」するのは適切なエチケットですか、それをそのままにして新しい機能に取り組むべきですか？前にも言ったように、私はOSSシーン全体に不慣れであり、チーム全体で作業しているので、混乱しないようにしたいと思います。

14 c#  open-source  etiquette 

私は過去にMVPとMVCを使用しましたが、MVPのほうが実行の流れを非常によく制御できるので、私の意見ではMVPを好んでいます。 インフラストラクチャ（データストア/リポジトリクラス）を作成し、サンプルデータをハードコーディングするときに問題なく使用できるので、GUIに移行してMVPを準備しています。 セクションA エントリポイントとしてビューを使用するMVPを見ました。つまり、ビューコンストラクターメソッドでプレゼンターを作成し、次にプレゼンターがモデルを作成し、必要に応じてイベントを関連付けます。 プレゼンターは、ビュー、モデル、プレゼンターが作成されるエントリポイントとしても見てきました。このプレゼンターには、コンストラクターでビューとモデルオブジェクトが与えられ、イベントを結び付けます。 2と同じですが、モデルはプレゼンターに渡されません。代わりに、モデルはメソッドが呼び出され、応答が直接返される静的クラスです。 セクションB 私が見たビューとモデルの同期を保つという点で。 ビューの値が変更されたとき、つまりTextChanged.Net / C＃のイベントが発生したとき。これDataChangedEventにより、モデルに渡されるa が起動され、常に同期が保たれます。そして、モデルが変化する場所、つまり、モデルがリッスンするバックグラウンドイベントの場合、ビューはを上げるという同じアイデアによって更新されDataChangedEventます。ユーザーが変更をコミットSaveEventしようとすると、モデルが起動して保存されます。この場合、モデルはビューのデータを模倣し、アクションを処理します。 ＃b1と同様ですが、ビューは常にモデルと同期しません。代わりに、ユーザーが変更をコミットしたい場合に起動SaveEventされ、プレゼンターは最新の詳細を取得してモデルに渡します。この場合、モデルは、それに基づいて行動する必要があるまでビューデータを認識しません。その場合、必要なすべての詳細が渡されます。 セクションC ビュー内のビジネスオブジェクト、つまりプリミティブデータ（int、double）ではなくオブジェクト（MyClass）の表示 ビューには、ドメイン/ビジネスオブジェクトとして表示されるすべてのデータのプロパティフィールドがあります。ビューはこれらをTreeViewのノードに処理しますが、プロパティをview.Animals公開するなどIEnumerable<IAnimal>。次に、選択した動物について、プロパティSelectedAnimalとして公開しIAnimalます。 ビューはドメインオブジェクトの知識を持たず、プリミティブ/フレームワーク（.Net / Java）に含まれるオブジェクトタイプのみのプロパティを公開します。この場合、プレゼンターはアダプターオブジェクトにドメインオブジェクトを渡し、アダプターは特定のビジネスオブジェクトをビューに表示されるコントロールに変換します。この場合、アダプターは、ビューだけでなく、ビューの実際のコントロールにアクセスできる必要があるため、より緊密に結合されます。 セクションD 単一のコントロールを作成するために使用される複数のビュー。つまり、さまざまなタイプのオブジェクトを保存するような単純なモデルを持つ複雑なビューがあります。適切なコントロールが表示される項目をクリックするたびに、メニューシステムを横に配置できます。 ビューインターフェイスを介して公開される個々のコントロールすべてを含む1つの巨大なビューを作成します。 いくつかのビューがあります。メニュー用のビューとブランクパネルが1つあります。このビューは、必要な他のビューを作成しますが、表示しません（visible = false）。このビューは、含まれる各ビュー（子ビュー）のインターフェイスも実装するため、1人のプレゼンターに公開できます。空白のパネルには、他のビュー（Controls.Add(myview)）および（(myview.visible = true）が表示されます。これらの「子」ビューで発生したイベントは、親ビューによって処理されます。親ビューは、イベントをプレゼンターに渡し、逆もまた同様です。 メインビューであれ小さなビューであれ、それぞれのビューは、それぞれ独自のプレゼンターとモデルに配線されます。ビューコントロールを既存のフォームに文字通りドロップするだけで、機能の準備が整い、舞台裏でプレゼンターに配線するだけで済みます。 セクションE すべてにインターフェースがある場合、上記の例でMVPがどのように行われるかに基づいて、相互互換性がない可能性があるため、この回答に影響します。 すべてには、View、Presenter、Modelというインターフェースがあります。これらのそれぞれは、明らかに具体的な実装を持っています。具体的なビューが1つしかない場合でも、モデルとプレゼンター。 ビューとモデルにはインターフェースがあります。これにより、ビューとモデルが異なります。プレゼンターは、ビューおよびモデルオブジェクトを作成/指定され、それらの間でメッセージを渡すだけです。 ビューのみにインターフェースがあります。モデルには静的メソッドがあり、作成されないため、インターフェースは不要です。別のモデルが必要な場合、プレゼンターは静的クラスメソッドの別のセットを呼び出します。モデルは静的であるため、プレゼンターへのリンクはありません。 個人的な考え 私が提示したすべての異なるバリエーション（ほとんどはおそらく何らかの形で使用しました）から、さらに多くのバリエーションがあると確信しています。A3は、MVPの外でビジネスロジックを再利用可能に保つこと、A2はデータの重複を減らし、発生するイベントを減らすことを好みます。C1は別のクラスに追加しないため、少量のユニットテスト不可能なロジックをビューに入れます（ドメインオブジェクトの視覚化方法）が、これはコードレビューするか、アプリケーションで単に表示することができます。ロジックが複雑な場合、アダプタークラスに同意しますが、すべての場合に同意するわけではありません。セクションDの場合、D1はメニューの例としては大きすぎるビューを作成すると感じています。以前にD2とD3を使用しました。D2の問題は、イベントをプレゼンターとの間で適切な子ビューにルーティングするために大量のコードを記述する必要があり、ドラッグ/ドロップ互換性がないことです。新しいコントロールごとに、単一のプレゼンターをサポートするためにより多くの配線が必要です。D3は私の好みの選択肢ですが、ビューが非常に単純であるか、再利用する必要がない場合でも、ビューを処理するプレゼンターおよびモデルとしてさらに多くのクラスを追加します。D2とD3の混合物は、状況に基づいて最適だと思います。セクションEに関しては、インターフェースを持つものはすべてやりすぎだと思うので、ドメイン/ビジネスオブジェクトに対しては既にそれを行っており、そうすることで「デザイン」に利点がないことがよくありますが、テストでオブジェクトをモックするのに役立ちます。個人的には、E2を古典的なソリューションと考えていますが、E3は以前に取り組んだ2つのプロジェクトで使用されています。D2とD3の混合物は、状況に基づいて最適だと思います。セクションEに関しては、インターフェースを持つものはすべてやりすぎだと思うので、ドメイン/ビジネスオブジェクトに対しては既にそれを行っており、そうすることで「デザイン」に利点がないことがよくありますが、テストでオブジェクトをモックするのに役立ちます。個人的には、E2を古典的なソリューションと考えていますが、E3は以前に取り組んだ2つのプロジェクトで使用されています。D2とD3の混合物は、状況に基づいて最適だと思います。セクションEに関しては、インターフェースを持つものはすべてやりすぎだと思うので、ドメイン/ビジネスオブジェクトに対しては既にそれを行っており、そうすることで「デザイン」に利点がないことがよくありますが、テストでオブジェクトをモックするのに役立ちます。個人的には、E2を古典的なソリューションと考えていますが、E3は以前に取り組んだ2つのプロジェクトで使用されています。 質問 MVPを正しく実装していますか？適切な方法はありますか？ バリエーションのあるマーティン・ファウラーの作品を読んだことがあり、MVCを始めたとき、コンセプトを理解していましたが、エントリポイントがどこにあるのか、すべてが独自の機能を持っていますが、オリジナルを制御して作成するものは元々理解できませんでしたMVCオブジェクトのセット。

14 c#  design  design-patterns  winforms 

私は最近、言語設定が.netプラットフォームで混在している新しい開発チームに参加しました。 開発者1：VB.netを知っているが、c＃を知らない 開発者2：VB.netを知っているが、c＃を知らない 開発者3：c＃とVB.netを知っており、c＃を好む 開発者4：C＃とVB6を知っている（VB.netは簡単に入手できるはずです）、C＃を好む .netスペースの思想的リーダーは、ほぼ普遍的にc＃開発者であるように思えます。また、サードパーティのツールの中にはVB.netをサポートしていないものもあると思いましたが、調査を始めたときに良い例が見つかりませんでした。 私はc＃でチーム全体を獲得したいと思いますが、好み以外に問題を強制する正当な理由がない場合、それは正しい選択だとは思いません。 VB.netから人々を遠ざけるべき理由はありますか？

14 c#  .net  vb.net 

私はC＃で作業しており、作成中の2つのアプリ間で通信を行っています。Web APIとJSONが好きになりました。現在、2つのサーバー間でテキストデータとファイルを含むレコードを送信するルーチンを作成しています。 インターネットによると、ここに示すようにmultipart / form-dataリクエストを使用することになっています。 SO質問「C＃クライアントからのマルチパートフォーム」 基本的に、次のような形式に従ってリクエストを手動で記述します。 Content-type: multipart/form-data, boundary=AaB03x --AaB03x content-disposition: form-data; name="field1" Joe Blow --AaB03x content-disposition: form-data; name="pics"; filename="file1.txt" Content-Type: text/plain ... contents of file1.txt ... --AaB03x-- RFC 1867-HTMLでのフォームベースのファイルアップロードからコピー この形式は、優れたJSONデータに慣れている人にとって非常に苦痛です。したがって、明らかに解決策は、JSONリクエストを作成し、Base64でファイルをエンコードして、次のようなリクエストで終わることです。 { "field1":"Joe Blow", "fileImage":"JVBERi0xLjUKJe..." } そして、好きな場所でJSONのシリアル化と逆シリアル化を利用できます。さらに、このデータを送信するコードは非常に簡単です。JSONシリアル化用のクラスを作成し、プロパティを設定するだけです。ファイル文字列プロパティは、いくつかの簡単な行で設定されます。 using (FileStream fs = File.Open(file_path, FileMode.Open, FileAccess.Read, FileShare.Read)) { byte[] file_bytes = …

14 c#  asp.net  json  file-handling  webforms 

私の現在のプロジェクトでは、同じ名前で汎用パラメーターの数が異なる汎用クラスを作成するという要件に直面しています。例えば： MyClass<T1> MyClass<T1, T2> MyClass<T1, T2, T3> これらすべてを同じ名前空間に入れたいので、クラスとファイルの構造と名前の付け方について混乱していますか？ クラスをファイルごとに1つに制限し、ファイルが名前空間階層を表すフォルダー構造にあり、ファイルの名前がクラスの名前と一致する必要があるという考えに従う場合、この状況にどのように対処しますか？ 私は本当にここに求めています、私は名前を付けるべきであるファイルが含まれMyClass<T1>、そしてどのような私は名前を付ける必要があるファイルが含まれMyClass<T1, T2>？型パラメータの名前はどうあるべきかを尋ねているのではありません。

14 c#  .net