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

Visual Studioでコードを書くとき、ReSharper（神のご加護を！）はしばしば、古い学校のforループをよりコンパクトなforeach形式に変更することを勧めます。 多くの場合、この変更を受け入れると、ReSharperは一歩前進し、光沢のあるLINQ形式で再度変更することを提案します。 だから、私は疑問に思う：これらの改善には、いくつかの本当の利点がありますか？非常に単純なコード実行では、速度の向上は見られませんが（明らかに）、コードがますます読みにくくなっているのがわかります。

86 c#  linq 

私は、C＃.NETで静的であるユニットテスト（モック/スタブ）依存関係に3つの方法しかないことを発見しました。 ほくろ TypeMock ジャストモック これらの2つが無料ではなく、1つがリリース1.0に達していないことを考えると、静的なものをモックするのは簡単ではありません。 それは静的な方法とそのような「悪」（ユニットテストの意味で）を作りますか？もしそうなら、なぜ再シャーパーは私に静的なもの、静的なものを作ることを望んでいますか？（再シャーパーも「悪」ではないと仮定します。） 明確化： メソッドのユニットテストを行い、そのメソッドが別のユニット/クラスで静的メソッドを呼び出す場合のシナリオについて説明しています。単体テストのほとんどの定義では、テスト対象のメソッドが他の単体/クラスの静的メソッドを呼び出すようにした場合、単体テストではなく、統合テストになります。（便利ですが、単体テストではありません。）

85 c#  unit-testing  static-methods  mocking 

リッチドメインモデルと貧血ドメインモデルの議論では、インターネットは哲学的なアドバイスに満ちていますが、権威のある例は不足しています。この質問の目的は、適切なドメイン駆動設計モデルの決定的なガイドラインと具体例を見つけることです。（理想的にはC＃で。） 実際の例では、このDDDの実装は間違っているようです。 以下のWorkItemドメインモデルは、Entity Frameworkがコードファーストデータベースに使用するプロパティバッグに他なりません。ファウラーごとに、それは貧血です。 WorkItemService層は、明らかにドメインサービスの一般的な誤解です。WorkItemのすべての動作/ビジネスロジックが含まれています。イェメリャノフなどによると、手続き型です。（ページ6） 以下が間違っている場合、どうすれば正しくできますか？AddStatusUpdateまたはCheckoutなど の動作はWorkItemクラスに属している必要がありますか？ WorkItemモデルにはどのような依存関係が必要ですか？ public class WorkItemService : IWorkItemService { private IUnitOfWorkFactory _unitOfWorkFactory; //using Unity for dependency injection public WorkItemService(IUnitOfWorkFactory unitOfWorkFactory) { _unitOfWorkFactory = unitOfWorkFactory; } public void AddStatusUpdate(int workItemId, int statusId) { using (var unitOfWork = _unitOfWorkFactory.GetUnitOfWork<IWorkItemUnitOfWork>()) { var workItemRepo = unitOfWork.WorkItemRepository; var workItemStatusRepo = …

84 c#  object-oriented  object-oriented-design  domain-driven-design 

クラスライブラリのメソッドまたはプロパティを記述する必要が生じることがありますが、実際の答えがなくても失敗することは例外ではありません。何かを判断できない、利用できない、見つからない、現在不可能、または利用可能なデータがもうない。 このような比較的例外的ではない状況で、C＃4の失敗を示す3つの解決策があると思います。 そうでなければ意味のないマジック値を返します（nullandなど-1）。 例外をスローします（例KeyNotFoundException）。 パラメータでfalse実際の戻り値を返し、提供しoutます（などDictionary<,>.TryGetValue）。 質問は次のとおりです。どの例外ではない状況で例外をスローする必要がありますか？そして、私が投げてはいけない場合：パラメータ付きのメソッドを実装する上で与えられた魔法の値を返すのはいつTry*outですか？（私にはoutパラメーターが汚れているようで、適切に使用するのはより手間がかかります。） 設計ガイドライン（Try*メソッドについては何も知りません）、使いやすさ（クラスライブラリを求めて）、BCLとの整合性、読みやすさなどの事実に関する答えを探しています。 .NET Framework基本クラスライブラリでは、3つのメソッドすべてが使用されます。 そうでなければ意味のないマジック値を返します。 Collection<T>.IndexOf -1を返します StreamReader.Read -1を返します Math.Sqrt NaNを返します。 Hashtable.Item nullを返します。 例外を投げる： Dictionary<,>.Item KeyNotFoundExceptionをスローします。 Double.ParseFormatExceptionをスローします。または パラメータfalseで実際の戻り値を返し、提供しoutます。 Dictionary<,>.TryGetValue、 Double.TryParse。 HashtableC＃にジェネリックがなかったときに作成されたように、それが使用され、objectしたがってnullマジック値として返されることに注意してください。しかし、ジェネリックでは、で例外が使用されてDictionary<,>おり、当初はありませんでしたTryGetValue。どうやら洞察が変わります。 明らかに、Item- TryGetValueとParse-のTryParse二重性は理由があるので、非例外的な障害に対して例外をスローすることはC＃4で行われていないと思います。ただし、Try*メソッドが存在した場合でも、常に存在するとは限りませんでしDictionary<,>.Itemた。

83 c#  .net  exceptions  error-handling 

長年のC＃プログラマーとして、最近、Resource Acquisition Is Initialization（RAII）の利点について詳しく知るようになりました。特に、C＃のイディオムは次のとおりです。 using (var dbConn = new DbConnection(connStr)) { // do stuff with dbConn } C ++に相当するものがあります。 { DbConnection dbConn(connStr); // do stuff with dbConn } つまりDbConnection、usingブロックのようにリソースの使用を囲むことを覚えておくことは、C ++では不要です。これは、C ++の大きな利点のようです。あなたはタイプのインスタンスメンバを持つクラスを考えるとき、これは、より説得力があるDbConnectionたとえば、 class Foo { DbConnection dbConn; // ... } C＃では、Foo IDisposableを次のように実装する必要があります。 class Foo : IDisposable { DbConnection dbConn; public void …

82 java  c#  c++  language-design 

最近、C＃プログラミングの仕事を始めましたが、Haskellにはかなりのバックグラウンドがあります。 しかし、私はC＃がオブジェクト指向言語であることを理解しています。丸い釘を四角い穴に押し込みたくありません。 私は、Microsoftからの例外のスローに関する記事を読みました。 エラーコードを返さないでください。 しかし、Haskellに慣れているため、C＃データ型を使用してOneOf、結果を「右」値として返すか、エラー（ほとんどの場合は列挙）を「左」値として返します。 これはEitherHaskell の慣習によく似ています。 私には、これは例外よりも安全に思えます。C＃では、例外を無視してもコンパイルエラーは発生しません。例外がキャッチされない場合は、プログラムがバブルアップしてクラッシュします。これはおそらく、エラーコードを無視して未定義の動作を生成するよりも優れていますが、クライアントのソフトウェアをクラッシュさせることは、特にバックグラウンドで他の多くの重要なビジネスタスクを実行している場合、まだ良いことではありません。 を使用してOneOf、パッケージを展開し、戻り値とエラーコードを処理することを明確にする必要があります。呼び出しスタックのその段階でそれを処理する方法がわからない場合は、現在の関数の戻り値に入れる必要があるため、呼び出し元はエラーが発生する可能性があることを知っています。 しかし、これはMicrosoftが提案するアプローチではないようです。 OneOf「通常の」例外（File Not Foundなど）を処理するために例外の代わりに使用するのは合理的なアプローチですか、それともひどい習慣ですか？ 制御フローとしての例外は深刻なアンチパターンと見なされていると聞いたことは注目に値します。したがって、「例外」がプログラムを終了せずに通常処理するものであれば、その「制御フロー」はある意味ではありませんか？ここに灰色の領域が少しあることを理解しています。 OneOf「メモリ不足」のようなものには使用していないことに注意してください。回復が期待できない条件でも例外がスローされます。しかし、解析されないユーザー入力は本質的に「制御フロー」であり、おそらく例外をスローすべきではないなど、かなり合理的な問題だと思います。 その後の考え： この議論から、私が現在取り上げていることは次のとおりです。 すぐに呼び出し元がcatch例外を処理し、ほとんどの場合例外を処理し、別のパスを介して作業を続行する場合は、おそらく戻り型の一部である必要があります。OptionalまたはOneOfここで役立ちます。 すぐに呼び出し元がほとんどの場合例外をキャッチしないと予想される場合は、例外をスローして、手動でスタックに渡す手間を省きます。 直近の発信者が何をしようとしているのかわからない場合は、Parseとなどの両方を提供しTryParseます。

80 c#  exceptions 

多くの点で、Fluentインターフェイスのアイデアは本当に好きですが、C＃の最新の機能（初期化子、ラムダ、名前付きパラメーター）のすべてで、「それだけの価値はありますか？」、「これは正しいパターンですか？」つかいます？"。Fluentパターンをいつ使用するかについて、少なくとも自分の経験や意思決定マトリックスを受け入れてもらえますか？ 結論： これまでの回答からのいくつかの良い経験則： 呼び出しはコンテキストパススルーの恩恵を受けるため、Fluentインターフェイスはセッターよりもアクションが多い場合に非常に役立ちます。 流Fluなインターフェイスは、唯一の使用方法ではなく、APIの上のレイヤーと考える必要があります。 ラムダ、初期化子、名前付きパラメーターなどの最新の機能は、連携して動作し、流canなインターフェイスをさらに使いやすくします。 必要性を感じさせないモダンな機能の意味の例を次に示します。たとえば、次のような従業員を作成できる（おそらく悪い例の）Fluentインターフェイスを考えてみましょう。 Employees.CreateNew().WithFirstName("Peter") .WithLastName("Gibbons") .WithManager() .WithFirstName("Bill") .WithLastName("Lumbergh") .WithTitle("Manager") .WithDepartment("Y2K"); 次のような初期化子で簡単に記述できます。 Employees.Add(new Employee() { FirstName = "Peter", LastName = "Gibbons", Manager = new Employee() { FirstName = "Bill", LastName = "Lumbergh", Title = "Manager", Department = "Y2K" } }); この例のコンストラクターで名前付きパラメーターを使用することもできます。

78 c#  .net 

私はC＃のAvSolコーディングガイドラインに目を通し、ほぼすべてに同意しましたが、特定のルールについて他の人がどう考えているかを知りたいと思います。 AV1500 メソッドは7つのステートメントを超えてはなりません。7つを超えるステートメントを必要とするメソッドは、処理が多すぎるか、責任が多すぎます。また、人間の心が正確なステートメントを分析して、コードが何をしているかを理解する必要があります。わかりやすい名前で、複数の小さくて焦点を絞った方法に分けてください。 あなたのほとんどはこのルールに従っていますか？読みやすさを大幅に向上させることは別として、新しいメソッドを作成すること（コードはまだDRYです）から節約できることはほとんどありませんか？そして、あなたの番号はまだ7と低いですか？私はもっ​​と10に向かう傾向があるでしょう。 私はあちこちでこの規則に違反していると言っているわけではありません。反対に、私の方法は95％小さくて集中していますが、この規則に違反してはいけないと言って本当に衝撃を受けました。 私は本当に誰もがこの規則に違反しないと思うことを知りたいだけです（コーディング標準の「1」です-これを絶対にしないでください）。しかし、そうでないコードベースを見つけるのに苦労すると思います。

78 c#  coding-standards  maintainability 

私はプログラマーの同僚と、テスト可能なものにするためだけに作業中のコードを変更するのが良いか悪いかについて議論しています（例えば、単体テストを介して）。 私の意見では、オブジェクト指向とソフトウェアエンジニアリングの優れた実践を維持することの範囲内で（「すべてを公開する」などではなく）OKです。 私の同僚の意見は、テスト目的でのみコードを修正するのは間違っているというものです。 単純な例として、一部のコンポーネント（C＃で記述された）で使用される次のコードを考えてください。 public void DoSomethingOnAllTypes() { var types = Assembly.GetExecutingAssembly().GetTypes(); foreach (var currentType in types) { // do something with this type (e.g: read it's attributes, process, etc). } } 私は、このコードを修正して、実際の作業を行う別のメソッドを呼び出すことを提案しました。 public void DoSomething(Assembly asm) { // not relying on Assembly.GetExecutingAssembly() anymore... } このメソッドは、作業するAssemblyオブジェクトを取り込んで、テストを実行するために独自のAssemblyを渡すことを可能にします。私の同僚は、これが良い習慣だとは思いませんでした。 良い一般的な慣行とは何ですか？

77 c#  programming-practices  testing  unit-testing  refactoring 

ほぼ4年間の経験の後、yieldキーワードが使用されているコードを見たことはありません。誰かがこのキーワードの（説明に沿って）実用的な使用法を私に示すことができますか？

76 c#  syntax 

私の理解では、このpartialキーワードはクラスを複数のソースファイルに分割することを許可するだけです。コードの整理以外にこれを行う理由はありますか？生成されたUIクラスで使用されているのを見ました。 キーワード全体を作成するのは不十分な理由のようです。クラスが複数のファイルを必要とするのに十分な大きさである場合、おそらくあまりにも多くのことを行っています。どこかで完了させる別のプログラマーのためにクラスを部分的に定義するために使用できると思いましたが、抽象クラスを作成する方が良いでしょう。

72 c#  design  language-design 

大規模なC＃プロジェクトの既存のコーディング標準には、すべての型名を完全修飾するというルールが含まれており、「using」ディレクティブの使用を禁止しています。だから、おなじみではなく： using System.Collections.Generic; .... other stuff .... List<string> myList = new List<string>(); （var禁止されていることはおそらく驚くことではありません。） 私は最終的に： System.Collections.Generic.List<string> myList = new System.Collections.Generic.List<string>(); それはタイピングの134％の増加であり、その増加のどれも有用な情報を提供しません。私の見解では、増加の100％は実際に理解を妨げるノイズ（混乱）です。 30年以上のプログラミングの中で、私はそのような標準が一度か二度提案されたのを見たことがありますが、実装されたことはありません。その背後にある理論的根拠は私を逃れます。標準を課している人は愚かではなく、私は彼が悪意があるとは思わない。私が何かを逃していない限り、それは他の唯一の選択肢として見当違いのままになります。 そのような標準が課されていることを聞いたことがありますか？もしそうなら、その背後にある理由は何でしたか？usingこの禁止を取り除くようにこの人に説得するかもしれない「それは愚かだ」または「他の誰もが採用している」以外の議論を考えることができますか？ 推論 この禁止の理由は次のとおりです。 完全に修飾された型を取得するには、名前の上にマウスを移動するのは面倒です。常に完全修飾型を常に表示することをお勧めします。 電子メールで送信されたコードスニペットには完全修飾名がないため、理解が難しい場合があります。 Visual Studioの外部（Notepad ++など）でコードを表示または編集する場合、完全修飾型名を取得することはできません。 私の主張は、3つすべてのケースがまれであり、少数のまれなケースに対応するためだけに、誰もが混乱して理解しにくいコードの代価を支払うようにすることは見当違いだということです。 潜在的な名前空間の競合の問題は、私が主な関心事であると予想していましたが、言及さえされていませんでした。名前空間があるためMyCompany.MyProject.Core、これは特に驚くべきことです。これは特に悪い考えです。何かを命名しSystemたりCore、C＃で命名することは、狂気への素早い道であることをずっと前に知りました。 他の人が指摘したように、名前空間の競合は、リファクタリング、名前空間のエイリアス、または部分的な修飾によって簡単に処理されます。

71 c#  coding-standards 

「抽象クラス」と「インターフェース」は類似した概念であり、インターフェースはより抽象的な概念です。1つの差別化要因は、抽象クラスが必要なときに派生クラスのメソッド実装を提供することです。ただし、C＃では、この差別化要因は、インターフェイスメソッドの実装を提供できる拡張メソッドの最近の導入によって削減されました。別の差別化要因は、クラスが1つの抽象クラスのみを継承できる（つまり、多重継承がない）が、複数のインターフェイスを実装できることです。これにより、インターフェイスの制限が緩和され、柔軟性が高まります。それでは、C＃では、拡張メソッドを備えたインターフェイスの代わりに抽象クラスをいつ使用すべきでしょうか？ インターフェイス+拡張メソッドモデルの注目すべき例はLINQです。ここではIEnumerable、多数の拡張メソッドを介して実装されるすべてのタイプに対してクエリ機能が提供されます。

70 c#  design  interfaces  inheritance  abstract-class 

私が知りたいのですが C＃またはVB.NETプロジェクトでは、ソース管理リポジトリ（Gitなど）にPACKAGEフォルダー（nupkgファイルおよびその他のコンテンツを含むプロジェクトのルートに作成されるナゲットパッケージフォルダー）を含める必要があります。

68 c#  version-control  git  vb.net 

Clean Codeの名前に関するボブおじさんの章では、主にハンガリーの表記法に関して、名前のエンコーディングを避けることを推奨しています。またI、インターフェイスからプレフィックスを削除することについて具体的に言及していますが、この例は示していません。 以下を想定してみましょう： インターフェイスの使用法は、主に依存性注入によりテスト容易性を実現することです 多くの場合、これは単一の実装者と単一のインターフェースを持つことにつながります それで、例えば、これらの2つは何と命名されるべきでしょうか？ParserそしてConcreteParser？ParserそしてParserImplementation？ public interface IParser { string Parse(string content); string Parse(FileInfo path); } public class Parser : IParser { // Implementations } または、このような単一実装の場合、この提案を無視する必要がありますか？

68 c#  naming  clean-code  naming-standards