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

過去には、通常、作成/更新されるプライマリメソッド内でオブジェクトのほとんどの操作を行ってきましたが、最近は別のアプローチを取っていることがわかりました。 以下に例を示します。Userエンティティを受け入れるリポジトリがあるとしますが、エンティティを挿入する前に、いくつかのメソッドを呼び出して、すべてのフィールドが必要なものに設定されていることを確認します。ここで、メソッドを呼び出してInsertメソッド内からフィールド値を設定するのではなく、挿入前にオブジェクトを整形する一連の準備メソッドを呼び出します。 古い方法： public void InsertUser(User user) { user.Username = GenerateUsername(user); user.Password = GeneratePassword(user); context.Users.Add(user); } 新しいメソッド： public void InsertUser(User user) { SetUsername(user); SetPassword(user); context.Users.Add(user); } private void SetUsername(User user) { var username = "random business logic"; user.Username = username; } private void SetPassword(User user) { var password = "more …

12 c#  design  coding-style 

クラスのインスタンスが変更されることを期待されていないとき、私はますます不変の型を使用しているようです。より多くの作業が必要になります（以下の例を参照）が、マルチスレッド環境での型の使用が簡単になります。 同時に、可変性がだれにも利益をもたらさない場合であっても、他のアプリケーションで不変型が表示されることはほとんどありません。 質問：不変の型が他のアプリケーションで使用されることがほとんどないのはなぜですか？ これは、不変型のコードを書くのが長いためです。 または、私は何かを見逃していて、不変の型を使用するときにいくつかの重要な欠点がありますか？ 実生活からの例 WeatherそのようなRESTful APIから取得するとしましょう。 public Weather FindWeather(string city) { // TODO: Load the JSON response from the RESTful API and translate it into an instance // of the Weather class. } 一般的に表示されるのは次のとおりです（コードを短縮するために新しい行とコメントが削除されています）。 public sealed class Weather { public City CorrespondingCity { get; set; } public SkyState …

12 c#  immutability 

環境 オブジェクトの階層（式ツリー）で「疑似」ビジターパターン（二重ディスパッチを使用しないように疑似）を使用しています。 public interface MyInterface { void Accept(SomeClass operationClass); } public class MyImpl : MyInterface { public void Accept(SomeClass operationClass) { operationClass.DoSomething(); operationClass.DoSomethingElse(); // ... and so on ... } } ただし、MyInterfaceの実装の数は非常に多く（〜50以上）、余分な操作を追加する必要がないため、この設計は疑わしく、かなり快適でした。 各実装は一意であり（異なる式または演算子です）、一部は複合（つまり、他の演算子/リーフノードを含む演算子ノード）です。 トラバーサルは現在、ツリーのルートノードでAccept操作を呼び出すことによって実行され、その操作は、その子ノードのそれぞれでAcceptを呼び出します。 しかし、きれいな印刷などの新しい操作を追加する必要があるときが来ました。 public class MyImpl : MyInterface { // Property does not come from MyInterface public string …

12 c#  design-patterns  object-oriented  visitor-pattern 

そのため、TDDを介してデータアクセスレイヤーを作成してきましたが、やや懸念がありました。私はむしろ間違った道を進んで行きたくないので、私の考えがきれいなアーキテクチャに沿っているかどうかを確認するように皆さんにお願いしたいと思いました。 私のデータアクセスレイヤー（略してDAL）内のメソッドは非常に単純です。これらはデータベース内のストアドプロシージャと一致しており（これを呼び出して物事をきれいにする方法はありません）、プロシージャと同じパラメータが含まれています。次に、データベースに接続し、クエリ結果を返します。次に例を示します。 public int DeleteRecord(int recordId) { recordId.RequireThat("recordId").NotZeroOrLess(); List<SqlParameter> parameters = new List<SqlParameter>(); parameters.Add(new SqlParameter { ParameterName = "@RecordId", SqlDbType = SqlDbType.Int, Direction = ParameterDirection.Input, Value = recordId}); return this.ExecuteNonQuery("DeleteRecord", parameters.ToArray()); } 私は結果セットで何も意味のあることをしていないので、これはこのタイプのメソッドには完全に機能します。コマンドが機能したことを確認したいだけなので、非クエリの結果、つまり影響を受けた行だけを返し、その番号を使用してロジックを検証できます。 ただし、別のDALメソッドで、レコードをロードしたいとします。マイロード手順が実行されようとしているselectsテーブルの束と戻っに対してDataSet、私はビジネスを作成する必要があり、私のDALは使用方法内のオブジェクトかどうかと戦っていますDataSet、または私のビジネスオブジェクトの場合自身がちょうど持っている必要がありますLoad()取得するメソッドをDataSetDALから、そして基本的にそれ自身を埋めます。 DALを介してそれを行うと、Business Objectsのロジックが少なくなります（これは単なる選択ロジックですが、それでもロジックです）が、DALを少し混雑させて、本当にすべきでないことをしているように感じさせますやってる 皆さんはどう思いますか？

12 c#  .net  architecture  database  business-logic 

私の会社のコードベース（.NET 3.5アプリケーション）のいたるところに次のコードパターンがあります。 bool Foo(int barID, out Baz bazObject) { try { // do stuff bazObject = someResponseObject; return true; } catch (Exception ex) { // log error return false; } } // calling code BazObject baz = new BazObject(); fooObject.Foo(barID, out baz); if (baz != null) { // do stuff …

12 c#  code-quality  coding-style 

私は「依存性注入の原則、実践、およびパターン」という本を読んでおり、この本で十分に説明されているリークのある抽象化の概念について読んでいます。 最近では、依存関係の注入を使用してC＃コードベースをリファクタリングし、非同期呼び出しをブロックの代わりに使用しています。そうすることで、コードベースの抽象化を表し、非同期呼び出しを使用できるように再設計する必要があるいくつかのインターフェイスを検討しています。 例として、アプリケーションユーザーのリポジトリを表す次のインターフェースについて考えてみます。 public interface IUserRepository { Task<IEnumerable<User>> GetAllAsync(); } 本の定義によれば、リークの多い抽象化は特定の実装を念頭に置いて設計された抽象化であり、一部の実装は抽象化自体を通じて「リーク」します。 私の質問は次のとおりです。IUserRepositoryなどの非同期を念頭に置いて設計されたインターフェイスを、漏れやすい抽象化の例として検討できますか？ もちろん、可能なすべての実装が非同期と関係があるわけではありません。アウトプロセス実装（SQL実装など）だけが必要ですが、インメモリリポジトリは非同期を必要としません（実際にインメモリバージョンのインターフェイスを実装する方がおそらくインターフェースが非同期メソッドを公開している場合は困難です。たとえば、メソッドの実装でTask.CompletedTaskまたはTask.FromResult（users）のようなものを返す必要がある場合があります。 あれについてどう思う ？

12 c#  object-oriented  api-design  interfaces  dependency-injection 

AOPを利用して、ビジネスロジックからロギングコードを削除できます。しかし、それは単純なもの（つまり、メソッドの入り口/出口およびパラメーター値のロギング）をログに記録するためにのみ使用できると思います。 ただし、ビジネスロジックに何かを記録する必要がある場合はどうなりますか？例えば public void SomeDomainMethod(string id) { //Get user by Id User user = Users.Get(id); if (user == null) { Log.Warn("user is not existed"); //<----------------- Log A throw new InvalidOperationException("user is not existed"); } //Step 1 while(true) { //do something } Log.Info("Step 1 is completed"); //<----------------- Log B //Step 2 …

12 c#  logging  separation-of-concerns 

私は電気技師で、一体何をしているのかわかりません。私のコードの将来のメンテナーを保存してください。 最近、機能が論理的に「手続き型」である（C＃の）いくつかの小さなプログラムに取り組んでいます。たとえば、その1つは、さまざまなデータベースから情報を収集し、その情報を使用して一種の要約ページを生成し、印刷してから終了するプログラムです。 これらすべてに必要なロジックは約2000行です。以前の開発者が行っていたように、私はそれらすべてを1つにmain()詰め込んで#regionsで「クリーンアップ」したくありません（シャダー）。 ここに私がすでに満足していないいくつかの試みがあります： DatabaseInfoGetter、SummaryPageGenerator、PrintUtilityなど、機能の粗いビットごとに静的ユーティリティを作成します。メイン関数を次のようにします。 int main() { var thisThing = DatabaseInfoGetter.GetThis(); var thatThing = DatabaseInfoGetter.GetThat(); var summary = SummaryPageGenerator.GeneratePage(thisThing, thatThing); PrintUtility.Print(summary); } 1つのプログラムでは、インターフェイスも使用しました int main() { /* pardon the psuedocode */ List<Function> toDoList = new List<Function>(); toDoList.Add(new DatabaseInfoGetter(serverUrl)); toDoList.Add(new SummaryPageGenerator()); toDoList.Add(new PrintUtility()); foreach (Function f in toDoList) f.Do(); } …

12 c#  object-oriented  code-quality  code-smell  procedural 

C＃ではstring、別のものstringを分割したい場合は、そのようなことをしなければなりません： testString.Split(new string[] { "anotherString" }, StringSplitOptions.None); オーバーロードされたString.SplitMSDNドキュメントから、実装とそのような呼び出しを行う必要がある理由を確認できます。 Pythonから来たので、なぜこのような呼び出しが必要なのかを正しく理解するのは難しいです。Regex.SplitPythonの実装と同様の構文を取得するために使用できましたが、単純なものではパフォーマンス（セットアップ時間）が低下するという犠牲を払う必要があります。 だから基本的に、私の質問は、なぜ地獄ができないのかということです： testString.Split("anotherString"); プロトタイプも実装も提案していないことに注意してください。現在のAPIを考慮して上記のバージョンを実装できない理由を理解しています。私の目標は、上記の構文がもたらす利点を考慮して、そのようなAPIが作成された理由を理解することでした。今のところ、柔軟性はString.Split理にかなった現在の目標のようですが、正直なところ、どこかで何らかのパフォーマンスの向上があると本当に思っていました。私は間違っていたと思います。

11 c#  performance  api-design 

IComparable 一方向にしか機能しない Employeeクラスがあるとしましょう。1つのビューでは、すべてEmployeesを名前でソートし、別のビューではアドレスでソートして表示します。どうやってそれを達成するつもりですか？ではなくIComparable、少なくとも慣用的な方法ではありません。 IComparable ロジックが間違った場所にある を呼び出すことにより、インターフェースが使用され.Sort()ます。Customer名前で並べ替えられたビューでは、並べ替え方法を示すコードはまったくありません。 一方、Customerクラスは、どのように使用されるかを想定しています-この場合、名前でソートされたリストで使用されることを想定しています。 IComparable 暗黙的に使用されます 代替と比較して、比較ロジックがどこで使用されているか、またはまったく使用されているかどうかを確認することは非常に困難です。標準IDEを想定し、Customerクラスから始めて、 へのすべての参照を検索 Customer リストで使用されている参照を見つける それらのリストが.Sort()それらを呼び出したことがあるかどうかを確認します さらに悪いことに、IComparableまだ使用されている実装を削除しても、エラーや警告は表示されません。あなたが得る唯一のものはあなたが考えるにはあまりにもあいまいだったすべての場所で間違った行動です。 これらの問題が組み合わさり、要件が変わります 私がこれについて考えるようになったまさにその理由は、それが私にとって間違っていたからです。私はIComparable2年前からアプリケーションで喜んで使用しています。ここで、要件が変更され、物を2つの異なる方法でソートする必要があります。前のセクションで説明した手順を実行するのは面白くないことに気づきました。 質問 これらの問題により、代替手段ではうまく機能しない有効なユースケースが見られないという点で、またはにIComparable劣ると考えるようになります。LINQまたはLINQ を使用する方が常に良いのですか、それとも、ここで見られない利点/ユースケースがありますか？IComparer.OrderBy() IComparer

11 c#  sorting  comparison 

次のような単体テストがあります。 [Test] public void Should_create_person() { Assert.DoesNotThrow(() => new Person(Guid.NewGuid(), new DateTime(1972, 01, 01)); } ここでPersonオブジェクトが作成された、つまり検証が失敗しないと断言しています。たとえば、Guidがnullの場合、または生年月日が1900年1月1日より前の場合、検証は失敗し、例外がスローされます（テストが失敗したことを意味します）。 コンストラクターは次のようになります。 public Person(Id id, DateTime dateOfBirth) : base(id) { if (dateOfBirth == null) throw new ArgumentNullException("Date of Birth"); elseif (dateOfBith < new DateTime(1900,01,01) throw new ArgumentException("Date of Birth"); DateOfBirth = dateOfBirth; } これはテストのための良いアイデアですか？ 注：ドメインモデルの単体テストに古典的なアプローチを採用している場合は、それが何らかの意味を持っています。

11 c#  unit-testing  constructors 

Javaと.NETには、メモリを管理するすばらしいガベージコレクターと、外部オブジェクト（Closeable、IDisposable）を迅速に解放する便利なパターンがありますが、それらは単一のオブジェクトによって所有されている場合のみです。一部のシステムでは、リソースは2つのコンポーネントによって個別に消費される必要があり、両方のコンポーネントがリソースを解放するときにのみ解放される場合があります。 最新のC ++ではshared_ptr、を使用してこの問題を解決しますshared_ptr。すべてのが破棄されると、リソースが確定的に解放されます。 オブジェクト指向の非決定論的にガベージコレクションされたシステムに単一の所有者がいない高価なリソースを管理およびリリースするための文書化された実証済みのパターンはありますか？

11 java  c#  design-patterns  garbage-collection  reference-counting 

私はそれ以来、MVCパターンを使用してGUIを設計しているC ++開発者です。 最近、C＃に戻りたいと思い、Windowsフォームアプリケーションをセットアップしましたが、MVC準拠の構造にプッシュする方法が少し失われました。 私が現在やろうとしていることは、WinFormsに与えられたクラスをビューとして「宣言」し、モデルとコントローラーのクラスをバックグラウンドで追加することです。ただし、ボタンのクリックなど、イベントと対話する方法についてはよくわかりません。通常、これらのイベントをコントローラーにリダイレクトし、完了したらビューでアクションを実行します。 しかし、これはこの星座ではかなり不満を感じます。たとえば、「Exit」ボタンを実装する場合、ViewからControllerにイベントをリダイレクトする必要があります。また、Viewに追加のパブリックメソッドを実装し、それをControllerから呼び出すことができます。最初のインスタンスのViewからClose（）を呼び出すだけです。 何かアドバイスはありますか？C＃でのWindows Formsの私の理解は、MVC実装を試すにはまだ十分ではありませんか？フォームクラスに間違った役割を与えていますか？MVCはこのユースケースにとって単に不適切なアーキテクチャですか？

11 c#  mvc  winforms 

次のインターフェースがあるとしましょう- interface IDatabase { string ConnectionString{get;set;} void ExecuteNoQuery(string sql); void ExecuteNoQuery(string[] sql); //Various other methods all requiring ConnectionString to be set } 前提条件は、いずれかのメソッドを実行する前にConnectionStringを設定/初期化する必要があることです。 IDatabaseが抽象クラスまたは具象クラスである場合、コンストラクターを介してconnectionStringを渡すことにより、この前提条件をある程度達成できます。 abstract class Database { public string ConnectionString{get;set;} public Database(string connectionString){ ConnectionString = connectionString;} public void ExecuteNoQuery(string sql); public void ExecuteNoQuery(string[] sql); //Various other methods all requiring …

11 c#  solid  liskov-substitution 

ビジネスロジックでは、次のようなメソッドが定義されている場合があります。 User.ResetCourse(Course courseToReset) 問題は、ユーザーとコースの両方がEntity Frameworkプロキシオブジェクトであるということです。つまり、ユーザーまたはコースのいずれかのナビゲーションプロパティにヒットすると、それらのオブジェクトはIQuery可能ではないため、通常どおりに繰り返されるため、データベースに大きなヒットを引き起こす可能性があります。 これを解決するために、署名を次のように変更しました。 User.ResetCourse(MyDBContext db, Course courseToReset) つまり、データベースに直接クエリを実行して必要な変更を効率的に行うことができますが、データベースコンテキストをビジネスオブジェクトに渡すことは非常に間違っているようです。 その後、ユーザーにサービスレイヤーを移行しました。つまり、次のようなものがあります。 CourseService.ResetForUser(Course courseToReset, User forUser) このサービスには、作成時に挿入されたDBContextへの参照がありますが、現在のビジネスオブジェクトは、動作のない単なるデータバッグです（つまり、Anemic Domain Model）。 どうすればこれを回避できますか？

11 c#  entity-framework  domain-model  business-logic