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

前に何度も質問がありましたが、特定の傾斜twds mvc開発がありました。 私は非常にいい子で、対応する単体テストですべてのコントローラーアクションをコーディングしてきました。正直に言うと、私は実際に初期のユニットテストのほとんどの骨を書くために小さなT4テンプレートを作成し、使用法に応じて適切に調整しました。パーシャルビューを含むビューでテストを処理する方法がよくわからないことは認めますが、それは別の質問の話です。 今、私が判断するのが難しい部分は、サービスレイヤーでカバレッジをどれだけ深くするかです。その理由は、私のサービスメソッドのいくつかは（良くも悪くも）実際にさまざまなlinqクエリを実行し、メソッド内の後続のロジックに個別の情報を提供するためです。私はこれらのメソッドを分解して、各linqステートメントに必要なロジックのみを呼び出し、メソッド内でそれらを適用できることを知っています。ただし、多くの場合、linqの「関数」の再利用は一切行われないため、これによりコードのレベルが過度にリファクタリングされると考えられます。 私が求めているのは、メソッド内で複雑なロジックが発生している場合、必要な結果および/または予想されるエラーを単にアサートするテストメソッドがあるか、すべてのロジックラインもシミュレートしてテストする必要があるということです。私が見ている方法、テストを正しく行うために、メソッドロジック（行ごと）も何らかの種類のカバレッジを取得する必要があります。しかし、それは（私の素朴な意見では）テストと実装されたメソッドをテスト自体にコテージ業界を作成するように密接に整列させようとする（私は彼らがそうであるべきだと知っています）ことを試みる終わりのないサイクルにつながる可能性があります。 私の質問は、これを簡単なこととは思わないTDD信者の一部を怒らせるかもしれません。TDDキャンプにいないので、これは私にとって「はい」ので、問題です。 ところで-アイデアのためにこれをチェックアウトしていました： http://dotnetslackers.com/articles/aspnet/Built-in-Unit-Test-for-ASP-NET-MVC-3-in-Visual-Studio-2010-Part-1.aspx 今着実にdownvotesにfwdを探しています:) [編集] -シングルの利益のために（今のところシングル!!）「近い」投票者。この質問は主観的なものではありません。私は非常に焦点を絞った主題に関するコンセンサスを探しています。私は否定的な情熱をかき立てようとはしていません。テクノロジーの欠陥を公開しようとは思っていません。私は大ファンです。したがって、曖昧さや誤報がある場合に質問を再構築するのに役立つ可能性があるため、閉会に投票する場合、私の利益のために丁寧なコメントをドロップしてください。この質問は、mvc人口の大部分に利益をもたらす可能性があります。 ありがとうございました！！ ジム

11 c#  .net  asp.net-mvc 

多くの検索を行った後、ソフトウェア開発の世界で知られていると思われるものに関する基本的な質問に答えることができませんでした。 知られていること： 適切なコードドキュメント（Doxygenタグ、Javadoc、または単なるコメントの豊富さ）に厳格なポリシーを適用すると、コードの開発に必要な時間がオーバーヘッドになります。 だが： 徹底的なドキュメント（またはAPI）を持っていると、新しい開発者やベテランの開発者が機能を追加したり、バグを修正したりするときに生産性が向上（想定）します。 質問： そのようなドキュメントを保証するために必要な追加の開発時間は、将来の生産性の向上によって相殺されますか（厳密に経済的な意味で）？ ケーススタディ、または導き出される結論を裏付ける客観的な証拠をもたらすことができる答えを探しています。 前もって感謝します！

11 java  c#  c++  documentation  coding-standards 

プラットフォームの独立性とはどういう意味ですか？言語プラットフォームを独立と呼ぶ基準は何ですか？クロスプラットフォームと「プラットフォームの独立性」は同じですか？ （これは自習用の質問かもしれませんが、スタックオーバーフローの専門家から聞きたいと思います。インターネットに関するそれに関する多くの定義と見解があり、それらのいくつかは混乱しています）

11 c#  java  cross-platform 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 私はソフトウェア会社に勤めていません。私は、プログラミングについて何かを知っている会社のほんの一握りの人の一人です。私は、パブリックAPIを介してオフィスで使用される他のプログラムの自動化に多くの時間を費やし、いくつかのスタンドアロンアプリケーションも作成しました。オフィスで使用していると思われるすべてのアプリケーションが何らかの形式の.NET APIを持っているように見えるため、私はほぼ完全にC＃.NETで作業しています。 ここで、「プログラムの作り方」について学び、どこから始めるべきかを尋ねる人が何人かいました。自動化したいプログラムのほぼすべてが.NET APIを備えているため、.NET言語を学習する方がはるかに理にかなっていると思います。 ただし、.NETが何であるかを説明し、プログラミングについて何も知らない人になぜ.NETを学習する必要があるのか​​を理解しようとしています。.NET言語と見なされる言語は多数あるため、実際には言語ではありません。さらに、「。NET」と「.NETフレームワーク」にはマイクロソフトが提供するライブラリに関するものがあるため、「。NETフレームワーク」には違いがあると思います。

11 c#  .net  teaching  communication  vb.net 

私たちは、3つのメソッドのように必要なだけの巨大なインターフェースを公開するサードパーティのサービスに依存しています。さらに、インターフェースは頻繁に変更されます... プロジェクトのクラスにインターフェイスをラップし、必要なメソッドのみを公開することにしました。 しかし、私は戻り値をどのように処理するべきかわかりません...インターフェイスは型のオブジェクトを返しますStorage。内部StorageModelには、の内部表現であるタイプがありますStorage。 マッパーで何を返しますか：StorageまたはStorageModel？StorageService挿入されたラッパーの依存関係を取得するDataServiceがあります。 現在、私は基本的に次のようにしています： public class StorageService { private readonly IExternalStorageWrapper externalStorageWrapper; public StorageService(IExternalStorageWrapper externalStorageWrapper) { this.externalStorageWrapper = externalStorageWrapper; } public StorageModel GetStorage(int storageId) { return this.externalStorageWrapper.GetStorage(storageId).ConvertToStorageModel(); } } public class ExternalStorageWrapper : IExternalStorageWrapper { public Storage GetStorage(int storageId) { using(var ext = new ExternalStorage()) { return ext.GetStorage(storageId); } …

11 c#  design-patterns  programming-practices  code-reviews  wrapper 

私たちのソフトウェアには、リフレクションを介して動的に検出されるいくつかのクラスがあります。すべてのクラスには、リフレクションコードがオブジェクトをインスタンス化する特定のシグネチャを持つコンストラクターがあります。 ただし、誰かがメソッドが参照されているかどうか（Visual Studio Code Lensなどを介して）を確認すると、リフレクションを介した参照はカウントされません。人々はそれらの参照を見逃し、明らかに未使用のメソッドを削除（または変更）することができます。 リフレクションを介して呼び出されるメソッドをマーク/ドキュメント化するにはどうすればよいですか？ 理想的には、メソッドは、同僚とVisual Studio / Roslynおよび他の自動化ツールの両方が、メソッドがリフレクションを介して呼び出されることが意図されていることを「確認」するような方法でマークする必要があります。 使用できる2つのオプションを知っていますが、どちらも十分に満足できるものではありません。Visual Studioは参照を見つけることができないので： カスタム属性を使用して、この属性でコンストラクタをマークします。 問題は、Attributeプロパティをメソッド参照にすることはできないため、コンストラクターは参照が0と表示されることです。 カスタム属性に慣れていない同僚はおそらくそれを無視するでしょう。 私の現在のアプローチの利点は、リフレクションパーツが属性を使用して、呼び出すコンストラクターを見つけることができることです。 コメントを使用して、メソッド/コンストラクターがリフレクションを介して呼び出されることを意図していることを文書化します。 自動化ツールはコメントを無視します（同僚もそうするかもしれません）。 XMLドキュメントコメントは、 Visual Studioがメソッド/コンストラクタへの追加の参照をカウント持つように使用することができます させるMyPluginそのコンストラクタ反射を経由して起動するためのクラスです。呼び出しリフレクションコードが、intパラメーターを受け取るコンストラクターを検索するとします。次のドキュメントでは、そのコードlensに、1つの参照を持つコンストラクターを示しています。 /// <see cref="MyPlugin.MyPlugin(int)"/> is invoked via reflection より良いオプションはどれですか？ リフレクションを介して呼び出されることを意図したメソッド/コンストラクターをマークするためのベストプラクティスは何ですか？

11 c#  .net  documentation  reflection 

私のWPFアプリケーションで、新しいビューを作成します。ViewModelまたはModelのどこでそれを行うべきですか？ アプリケーションは（今のところ非常にシンプルです）、1つの「送信」ボタンを備えた1ウィンドウフォームのようなツールです。チェックボックスの1つが選択されている場合、同じViewModelを使用する新しいウィンドウがポップアップし、追加の詳細をユーザーに尋ねます。この質問の目的のために、表示/非表示のパネルなどの別のアプローチを考慮せずに、新しいウィンドウのアプローチのみを検討してみましょう。 理想的には、Viewにはコードがないはずです。さらに、Viewにはロジックが含まれていないため、VMは最初に新しいビューの作成が必要かどうかを確認する必要があり、必要な場合はこの責任をViewに戻して、コードの膨張につながります。 一方、ViewModelで新しいビューを作成すると、ViewModelがViewについて何も認識してはならないという原則に違反します。 では、ViewまたはViewModelで新しいビューを作成する方が良いでしょうか？

11 c#  design  wpf  mvvm 

次のようなブール式を書いています。 team.Category == "A Team" && team?.Manager?.IsVietnamVet public class Manager { public bool IsVietnamVet { get; set; } } public class Team { public string Category { get; set; } public Manager Manager { get; set; } } ...そしてエラーが発生します： 演算子 '&&'は、タイプ 'bool'および 'bool？'のオペランドには適用できません。 それを処理するための最適/クリーンな方法は何ですか？ team.Category == "A Team" && (team?.Manager?.IsVietnamVet …

11 c# 

データベースにオブジェクトを保存したり、データベースからオブジェクトを取得したりするクラス（リポジトリ）がいくつかあります。それらすべてが1つのデータベースへの接続を確立する必要があります。 各クラスでConnectionStringとを再定義しないようにSqlConnection、オープン接続をそれらに渡すことを考えました。次に、その接続を定義/オープンしてクラスに渡すのに最適な場所/時間はいつ/どこですか？ この共通のリソースにアクセスするためのより良いアプローチ/パターンはありますか？

11 c#  sql  class-design 

C＃の複雑さを研究しているときに、明示的なインターフェイスの実装に関する興味深い一節に出会いました。 While this syntax is quite helpful when you need to resolve name clashes, you can use explicit interface implementation simply to hide more "advanced" members from the object level. の使用を許可するobject.method()か、キャストを要求するかの違いは((Interface)object).method()、経験の浅い目には意地悪な難読化のようです。テキストでは、これによりオブジェクトレベルでIntellisenseからメソッドが非表示になることが示されていますが、名前の競合を回避する必要がないのに、なぜそうする必要があるのでしょうか。

11 c#  design  interfaces 

MacでネイティブにC＃/。NET 4.0コードを実行するためにMicrosoftがサポートしているオプションがある場合はどうなりますか？はい、私はMonoについて知っていますが、とりわけMicrosoftよりも遅れています。また、SilverlightはWebブラウザーでのみ機能します。VMWareタイプのソリューションもそれを削減しません。 MicrosoftがMac自体で.NETをサポートしていない理由について、半権威的な答えはありますか？SilverlightやMonoを購入してすぐに利用できるように思えます。ネイティブのVisual Studioは必要ありません。クロスコンパイルとリモートデバッグは問題ありません。 その理由は、私が仕事をしていると、将来についての不確実性が高まり、C＃ではなくC ++でより多くの開発が行われるようになるためです。まったく新しいプロジェクトがC ++の使用を選択しています。Mac（またはiPad）が必要になった場合、誰も今から18〜24か月後に "申し訳ありません"と経営陣に伝えたくありません。C ++は、（おそらく）今日の生産性の低下を意味するとしても、より安全なオプションと見なされています。

11 c#  .net  mac  mono 

複数の実行可能ファイルで使用されるC＃ライブラリがあります。ライブラリには名前空間がいくつかありますが、名前空間の1つにかなりの数のクラスが含まれていることに気づきました。分類のため、そして無意識のうちに、名前空間のより深い階層を持つことは「きれい」に見えるため、単一の名前空間にあまり多くのクラスを含めることを常に避けてきました。 私の質問は、名前空間に多くのクラスがある場合、クラスが互いに関連している場合でも、他の誰かがそれを「コードのにおい」と見なしますか？サブカテゴリー化を可能にするクラスでニュアンスを見つけるために多くの努力をしますか？

11 c#  count  namespace 

私が研究したDDDに関するチュートリアルの多くは、主に理論をカバーしています。それらはすべて基本的なコード例（Pluralsightなど）を持っています。 Webでは、EFを使用したDDDをカバーするチュートリアルを作成しようとする試みも数人います。それらをほんの少しだけ調べ始めると、それらは互いに大きく異なることにすぐに気づきます。一部の人々は、アプリを最小限に保ち、追加のレイヤー（EFの上にリポジトリなど）を導入することを避けることを推奨します。他の人々は、追加のレイヤーを決定的に生成し、多くの場合、DbContext集約ルートに注入することによってSRPに違反します。 私が意見に基づく質問をしている場合、私はひどくお詫びしますが... 実践に関しては、Entity Frameworkは最も強力で広く使用されているORMの1つです。残念ながら、DDDに関する包括的なコースは見つかりません。 重要な側面： Entity Frameworkは、UoW＆リポジトリ（DbSet）をすぐに使用できるようにします EFでは、モデルにナビゲーションプロパティがあります EFでは、すべてのモデルが常にオフで使用できますDbContext（それらはとして表されますDbSet） 落とし穴： あなたがすることはできません、あなたのモデルは、ナビゲーションプロパティを持っており、それが彼らとのコールを変更することができます-あなたの子供のモデルのみ集約ルートを経由して影響を受けている保証しますdbContext.SaveChanges() でDbContext、あなたはこのように、あなたのすべてのモデルにアクセスすることができます回避集約ルートを あなたは、経由ルートオブジェクトの子へのアクセスを制限することができますModelBuilderでのOnModelCreating法分野としてそれらをマークすることにより、（私はまだそれがDDDについて移動する正しい方法だとは思わないそれに加えて、これは将来的ににつながる可能性の冒険の種類何を評価するのは難しい- 非常に懐疑的） 矛盾： Aggregateを返すリポジトリの別のレイヤーを実装しないと、上記の落とし穴を部分的に解決することさえできません リポジトリーの追加レイヤーを実装することにより、EFの組み込み機能（すべてDbSetがすでにレポです）を無視し、アプリを複雑にします。 私の結論： 私の無知を許してください、しかし上記の情報に基づいてください-それはエンティティフレームワークがドメイン駆動設計に適切でないか、ドメイン駆動設計が不完全で時代遅れのアプローチであるかのいずれかです。 それぞれのアプローチにはメリットがあると思いますが、私は今完全に道に迷っており、EFとDDDをどのように調整するかについて少し考えていません。 私が間違っている場合-EFでDDDを実行する方法の簡単な一連の手順を詳細に説明できますか（または適切なコード例を提供できますか）。

11 c#  design-patterns  object-oriented-design  domain-driven-design  entity-framework 

公開SDKでは、例外が発生する理由について非常に有益なメッセージを提供する傾向があります。例えば： if (interfaceInstance == null) { string errMsg = string.Format( "Construction of Action Argument: {0}, via the empty constructor worked, but type: {1} could not be cast to type {2}.", ParameterInfo.Name, ParameterInfo.ParameterType, typeof(IParameter) ); throw new InvalidOperationException(errMsg); } ただし、コードが何をしているのかではなく、エラーメッセージに重点を置く傾向があるため、コードの流れが煩雑になる傾向があります。 同僚は、次のようなものにスローする例外の一部をリファクタリングし始めました： if (interfaceInstance == null) throw EmptyConstructor(); ... private Exception EmptyConstructor() …

11 c#  .net  clean-code  exception-handling 

私の質問は強く型付けされた言語に関係しますが、SwiftでUserオブジェクトを作成します。ユーザーは多数のリンク（FacebookProfile、InstagramProfileなど）を持つことができます。これに関するいくつかの質問。 リンクを独自のオブジェクトでラップすることは良い習慣ですか？ struct User { var firstName：文字列 var lastName：文字列 var email：string varリンク：リンク } 構造体リンク{ var facebook：string var instagram：文字列 var twitter：文字列 } それともルーズにすべきですか？技術的にはどちらの方法でも問題ないことはわかっていますが、一般的に、特に読みやすさのために、推奨されるアプローチがあるかどうか疑問に思います。 struct User { var firstName: string var lastName: string var email: string var facebookLink: string var twitterLink: string var instagramLink: string } このようなシナリオでは、リンクはコレクション/リストにする必要がありますか？利用可能なリンクオプションの数は決まっているため、リストの数にしないでください。数は増えていません。私の考えは正しいですか？ getUsers、getUser、updateUserなどのユーザーオブジェクト内にネットワークメソッドを配置することは良い習慣ですか？ これらは主観的である可能性があることは知っていますが、同様の状況でのベストプラクティスを理解しようとしています。任意のポインタをいただければ幸いです。

10 java  c#  object-oriented  data-structures  swift-language