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

C#は、Microsoftが.NETプラットフォームと並行して作成した、マルチパラダイムで管理されたガベージコレクションのオブジェクト指向プログラミング言語です。

5
C#のジェネリック型の適切な命名規則は何ですか?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 かなり主観的であるため、スタックオーバーフローではなく、ここでこの質問をすることにしました。 C#では、通常、非常に貧弱な名前のジェネリック型が表示されます。特に、「T」は一般的に使用されますが、それ自体では意味のある名前ではありません。例えば: class Fruit<T> { T fruit; } これは典型的なアプローチですが、これに反対する人はいますか?もしそうなら、一般的な関数とクラスのC#のコンテキストでの一般的な型の合理的な命名規則は何でしょうか? 前の例では、ジェネリック型Tは常にAppleor などの果物の型である必要があると仮定しましょうOrange。タイプは、Tそれは明らかに、それは果物の種類だことを確認する必要があるので、多分、より良い名前のようになりFruitType、我々はで終わるので、: class Fruit<FruitType> { FruitType fruit; } これは、皆さんに私が探しているもののアイデアを提供するためのものです。この問題で受け入れられる「経験則」とは何ですか?
16 c#  naming  generics 


2
すべての.NETの人が知っておくべき主なプラクティスと設計パターンは何ですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 プロのプログラマーとしての短い時間で、教育を受けたプログラマーによって書かれた多くのアプリケーションを、.NET 2.0ブックの最初の数章を読んでいるように見ました。 私が始めたとき、私はそれらのアプリケーションのほとんどを書きました! AWESOME .NETアプリケーションを作成するために重要な最大の設計パターンは何ですか? 素晴らしいとは、私も内側を意味します!

8
LINQシニアインタビューの質問[終了]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 シニアプログラマー向けのインタビューの質問のLINQセクションを準備しています。LINQで最も興味深い質問は何ですか?なぜ?
16 c#  .net  interview  linq 

10
C#デリゲートの実際の使用[終了]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 私は概念的にはC#デリゲートを理解していると思いますが、それらが役立つ実際の例を見つけるのに苦労しています。実際のアプリケーションでC#デリゲートがどのように使用されたのか、どのような問題により回避できるのかを詳しく説明してください。
16 c#  delegates 

6
手続き型からオブジェクト指向コードへの変換
大規模なASP.NET Webフォームアプリケーションの既存のコードベースのクリーンアップを開始する方法に関する戦略を学習することを目的として、「レガシーコードとクリーンコードの効果的な使用」を読んでいます。 このシステムは2005年から使用されており、それ以来多くの機能強化が行われています。もともと、コードは次のように構成されていました(そして、まだ大部分はこのように構成されています): ASP.NET(aspx / ascx) コードビハインド(c#) ビジネスロジックレイヤー(c#) データアクセス層(c#) データベース(Oracle) 主な問題は、コードがオブジェクト指向のように手続き的に偽装されていることです。これは、両方の本で説明されているすべてのガイドラインに事実上違反しています。 これは、ビジネスロジックレイヤーの典型的なクラスの例です。 public class AddressBO { public TransferObject GetAddress(string addressID) { if (StringUtils.IsNull(addressID)) { throw new ValidationException("Address ID must be entered"); } AddressDAO addressDAO = new AddressDAO(); return addressDAO.GetAddress(addressID); } public TransferObject Insert(TransferObject addressDetails) { if (StringUtils.IsNull(addressDetails.GetString("EVENT_ID")) || StringUtils.IsNull(addressDetails.GetString("LOCALITY")) || …

4
TimeZoneに基づいてDateTimeを保存するためのベストプラクティス
ユーザーがTimeZoneに基づいて予定をスケジュールできるWebアプリケーションを開発します。そして、ユーザーの予定日時をサーバー日時としてデータベースフィールドに保存しています。スケジュール情報を表示しながら、データベースから値を取得し、ユーザーtimzoneに変換しました。コードベースでの処理ユーザーのタイムゾーンに基づいてDateTimeを変換しています。このベストプラクティスなのか、それとも簡単な方法が存在するのか教えてください。

5
オブジェクトを同じメソッドに2回渡すか、結合されたインターフェイスで統合しますか?
デジタルボードと通信した後にデータファイルを作成する方法があります。 CreateDataFile(IFileAccess boardFileAccess, IMeasurer boardMeasurer) ここではboardFileAccessとboardMeasurerの同じインスタンスですBoardその実装するオブジェクトの両方IFileAccessとIMeasurer。IMeasurerこの場合、ボード上の1つのピンをアクティブに設定して簡単な測定を行う単一の方法に使用されます。この測定からのデータは、を使用してボードにローカルに保存されIFileAccessます。Board別のプロジェクトにあります。 私はCreateDataFile、簡単な測定を行ってからデータを保存することで1つのことを行うという結論に達しました。同じ方法で両方を行うことは、このコードを使用して測定を行ってファイルに書き込む必要がある他の人にとってより直感的です個別のメソッド呼び出しとして。 私には、同じオブジェクトをメソッドに2回渡すのは厄介に思えます。IDataFileCreator拡張IFileAccessし、必要なメソッドを呼び出すだけのインスタンスをIMeasurer含む実装を持つローカルインターフェイスを作成することを検討しました。同じボードオブジェクトが常に測定とファイル書き込みに使用されることを考えると、同じオブジェクトをメソッドに2回渡すのは悪い習慣ですか?もしそうなら、ローカルインターフェイスと実装を使用して適切なソリューションですか?BoardBoard

4
サイズ、インデックスなどの場合はsize_tまたはint
C ++では、size_t(または、より正確にはT::size_type「通常」であるsize_t、すなわち、unsignedタイプ)の戻り値として使用されsize()、引数operator[]等、(参照std::vector、ら。)。 一方、.NET言語は同じ目的でint(および、オプションでlong)を使用します。実際、CLS準拠の言語は、符号なしの型をサポートする必要はありません。 .NETがC ++よりも新しいことを考えると、配列インデックスや長さのように「おそらく」負になれないものでも使用に問題があるかもしれunsigned intないということがわかります。後方互換性のためのC ++アプローチは「歴史的なアーティファクト」ですか?または、2つのアプローチの間に実際の重要な設計上のトレードオフがありますか? なぜこれが重要なのですか?さて... C ++の新しい多次元クラスには何を使うべきですか。size_tまたはint? struct Foo final // e.g., image, matrix, etc. { typedef int32_t /* or int64_t*/ dimension_type; // *OR* always "size_t" ? typedef size_t size_type; // c.f., std::vector<> dimension_type bar_; // maybe rows, or x dimension_type baz_; // e.g., columns, or y …
15 c#  c++  array 

3
refと実行時のoutの違いは何ですか?
C#は、参照によって渡される引数を作成するためのrefand outキーワードを提供します。2つのセマンティックは非常に似ています。唯一の違いは、フラグ付き変数の初期化です。 ref関数に渡す前に変数を初期化する必要がありますが、必要ありoutません。 out関数内で変数を初期化する必要がありますが、必要ありrefません。 これらの2つのキーワードの使用例もほぼ同じであり、あまりにも頻繁に使用されるため、コードのにおいと見なされます(TryParseandやTryGetValuepattern などの有効な使用例もあります)。 このため、誰かが説明できますが、なぜC#には非常に狭いユースケース用の2つの非常に類似したツールがあるのですか? また、MSDNでは、実行時の動作が異なることが記載されています。 refキーワードとoutキーワードは異なる実行時の動作を引き起こしますが、コンパイル時のメソッドシグネチャの一部とは見なされません。 実行時の動作はどのように異なりますか? 結論 両方の答えが正しいように見えます、ありがとう。jmorenoを受け入れたのは、より明確だからです。

3
依存関係の注入を取得しますが、IoCコンテナーの必要性を理解するのを手伝ってもらえますか?
これが質問のさらに別の繰り返しのように思える場合は申し訳ありませんが、トピックに関する記事を見つけるたびに、それは主にDIとは何かについて話します。だから、私はDIを取得しますが、誰もが入ろうとしているIoCコンテナの必要性を理解しようとしています。IoCコンテナのポイントは、依存関係の具体的な実装を単に「自動解決」することですか?私のクラスにはいくつかの依存関係がない傾向があるかもしれませんし、それが大したことではないのかもしれませんが、コンテナのユーティリティを正しく理解していることを確認したいです。 私は通常、ビジネスロジックを次のようなクラスに分類します。 public class SomeBusinessOperation { private readonly IDataRepository _repository; public SomeBusinessOperation(IDataRespository repository = null) { _repository = repository ?? new ConcreteRepository(); } public SomeType Run(SomeRequestType request) { // do work... var results = _repository.GetThings(request); return results; } } そのため、依存関係は1つだけであり、場合によっては2番目または3番目の依存関係がありますが、それほど頻繁ではありません。そのため、これを呼び出すものはすべて、それ自身のレポを渡すか、デフォルトのレポを使用することができます。 IoCコンテナに関する私の現在の理解に関する限り、コンテナが行うことはIDataRepositoryを解決することだけです。しかし、それがすべてである場合、依存関係が渡されないときに私の操作クラスがすでにフォールバックを定義しているため、大量の値が表示されていません。これは同じフォールバックリポジトリを使用します。レジストリ/工場/コンテナの1つの場所でそのリポジトリを変更できます。それは素晴らしいことですが、それはそれですか?

2
これは、ドメイン駆動設計のRESTful Webサービスに適したVisual Studioソリューション構造ですか?
私は.NET 4.5 C#Web API RESTfulソリューションを構築していますが、ドメイン駆動設計を使用して設計されたソリューションのプロジェクトソリューションが正しいか、賢明であるか(または十分ですか)を教えてください。 ソリューションは6つのプロジェクトに分割されました。 /ベース (何にも参照されない) Webプロジェクトは、ソリューションと外部の世界との間のインターフェースを形成します。Web APIコントローラーが含まれています。要求オブジェクトから値を収集し、BizApiレイヤーに作業を依頼する以外のロジックはほとんど含まれていません。 /Biz.Api (ベースで参照]) ドメインサービスを提供し、/ Baseインターフェイスプロジェクトが/Biz.Domainプロジェクトのドメインビジネスロジックオブジェクトにアクセスできるようにします。 /Biz.Domain (Biz.Apiが参照) Biz.Apiレイヤーのドメインクラスを提供します。これらは、メモリ内のビジネスのデータを操作するメソッドを提供します。 /Dal.Db (Biz.Apiが参照) データベースリポジトリレイヤー。データベースにアクセスし、返されたデータを/ Interfacesレイヤーで定義された内部DTOにマップします。 /Dal.Services (Biz.Apiが参照) Webサービスなどの外部の依存関係にプロキシレイヤーを提供し、返されたデータを/ Interfacesプロジェクトで定義された内部DTOにマップします。 /インターフェース (上記のほとんどのプロジェクトで参照) ソリューションにデータを渡すためのDTOクラスと、IoCなどのコントラクトを定義するC#インターフェイスが含まれています。

5
カプセル化を壊さずに依存性注入を使用できますか?
ここに私のソリューションとプロジェクトがあります: BookStore (ソリューション) BookStore.Coupler (プロジェクト) Bootstrapper.cs BookStore.Domain (プロジェクト) CreateBookCommandValidator.cs CompositeValidator.cs IValidate.cs IValidator.cs ICommandHandler.cs BookStore.Infrastructure (プロジェクト) CreateBookCommandHandler.cs ValidationCommandHandlerDecorator.cs BookStore.Web (プロジェクト) Global.asax BookStore.BatchProcesses (プロジェクト) Program.cs Bootstrapper.cs: public static class Bootstrapper.cs { // I'm using SimpleInjector as my DI Container public static void Initialize(Container container) { container.RegisterManyForOpenGeneric(typeof(ICommandHandler<>), typeof(CreateBookCommandHandler).Assembly); container.RegisterDecorator(typeof(ICommandHandler<>), typeof(ValidationCommandHandlerDecorator<>)); container.RegisterManyForOpenGeneric(typeof(IValidate<>), AccessibilityOption.PublicTypesOnly, (serviceType, …

2
コンストラクタの代わりにファクトリメソッドを使用する必要がありました。それを変更しても下位互換性はありますか?
問題 ファイルからデータを読み取るためのメソッドDataSourceを提供するクラスReadData(および他のクラスもありますが、物事をシンプルにしましょう)があるとし.mdbます。 var source = new DataSource("myFile.mdb"); var data = source.ReadData(); 数年後、データソースとして.xmlファイルに加えて.mdbファイルもサポートできるようにしたいと決めました。「データの読み取り」の実装は.xml、.mdbファイルとファイルでまったく異なります。したがって、システムをゼロから設計する場合、次のように定義します。 abstract class DataSource { abstract Data ReadData(); static DataSource OpenDataSource(string fileName) { // return MdbDataSource or XmlDataSource, as appropriate } } class MdbDataSource : DataSource { override Data ReadData() { /* implementation 1 */ } } class XmlDataSource …

5
インターフェイスに代わる機能プログラミングとは何ですか?
「機能的な」スタイルでプログラミングしたい場合、インターフェイスを何に置き換えますか? interface IFace { string Name { get; set; } int Id { get; } } class Foo : IFace { ... } たぶんTuple<>? Tuple<Func<string> /*get_Name*/, Action<String> /*set_Name*/, Func<int> /*get_Id*/> Foo; そもそもインターフェイスを使用している唯一の理由は、特定のプロパティ/メソッドを常に利用できるようにしたいからです。 編集:私が考えている/試みていることについてのいくつかの詳細。 たとえば、次の3つの関数を取るメソッドがあります。 static class Blarf { public static void DoSomething(Func<string> getName, Action<string> setName, Func<int> getId); } Bar私のインスタンスでこのメソッドを使用できます: class …

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.