s_ryuukiのブックマーク - はてなブックマーク

オブジェクト指向は業務システムで本当に不要なのか？ - Qiita

主旨以前はシステムの状態をオブジェクト指向でカプセル化し、オブジェクト同士の通信でシステムの制御をしようとしていたしかし、Webアプリケーションのように状態をメモリ上に保持し続けるのが難しい環境が増えると、上記のことがやりにくくなった（ORMのインピーダンスミスマッチの影響が大きくなった）現在では、システム全体の状態を管理するためにオブジェクト指向を用いるシーンは減っているが、要所要所でシステムを抽象化する道具の一つとして用いるシーンはあり、適材適所で使い続ければ良いはじめに一時期あれだけもてはやされた「オブジェクト指向」ですが、現在では「業務システム開発においてオブジェクト指向で作るとろくなことがない」、とか、いっそ「不要である」、という意見もよく見かけます。オブジェクト指向、この記事では特に「オブジェクト指向プログラミング」を対象として話をしますが、その利点は以下の３点に集

s_ryuuki 2024/02/13

オブジェクト指向

リンク

[C#]DIコンテナのスコープ範囲を制御する - Qiita

概要 ASP.NET Coreのコントローラから呼び出しているScopedサービスのクラスをバッチ処理からも呼び出そうとしたらエラーになった原因はDIコンテナのスコープ範囲（ASP.NET Coreではリクエスト単位）がバッチ処理だと違ってくる為だった ASP.NET Coreと同様に、処理の呼び出し毎にDIコンテナのスコープを生成するようにしたらうまくいった内容次のようなASP.NET Coreのコントローラがあり、その中でMyLogicのDoWorkAsyncメソッドを呼び出している。 MyLogicには様々なScopedサービスが注入されており、DIコンテナを利用してコントローラに注入される。 ASP.NET Coreではサービスのスコープ範囲は「リクエスト単位」である為、DoWorkAsyncの呼び出しも基本、1回毎に異なるスコープで呼び出されることになる。 public c

s_ryuuki 2023/10/02

C#
DI

リンク

非同期なHTMLのレンダリングもサーバ側から全部やっちゃう「Blazor Server」が凄すぎる - Qiita

※Blazor Serverについて知らなかった人に興味を持ってもらいやすくする為、タイトルを「Blazor Serverの非同期処理がめちゃくちゃ直感的に書けて感激した件」から変更しました。今更ですがBlazor Serverをちょっと試してみて、そのあまりのすごさに驚いたので記事にしてみます。C#があれば、ReactもVueもSvelteも要らんかったんや…（言い過ぎ）。 Blazor Serverは比較的新しいフレームワークで、「サーバ側もクライアント側も全てC#で記述しよう」という野心的なフレームワークです。2020年頃に正式リリースされ、.NET 3.1以降で使えるので、.NET6がLTSで既に.NET8がリリースされようとしている現在では、割と安定した技術と言えるでしょう。同じBlazorブランドで展開している似た技術に「Blazor WebAssembly」というものもあ

s_ryuuki 2023/09/12

リンク

EF Coreで正しくUPDATEする方法 - Qiita

EF CoreのUpdateは結構勘違いされている海外オフショアの方が作成したソースコードのメンテナンスをしているのですが、EF Coreでのレコード更新処理がとても無駄の多いものになっていました。恐らく、EF Coreに対する根本的な勘違いがあるように思います。正しい理解の促進のためにこの記事を書きます。主なポイントは次の2つです。更新の為にDbContext.Update(entity) を呼び出す必要は（必ずしも）ありません更新する前にエンティティをDBから取得する必要は（必ずしも）ありません無駄の多いソースコード以下のコードは正しく動作しますが、無駄が多く、ある意味間違っています。 // DBからエンティティを取得 var article = await _context.Article.FindAsync(model.Id); // 入力値をエンティティに反映 ar

s_ryuuki 2023/05/14

リンク

[C#].NET6でnullチェックからおさらば！ - Qiita

if ( result?.list?.Length > 0 ) { // result?.list?.Any() の方が見やすいが、後々の説明の為にLengthを使用 // 処理 }

s_ryuuki 2023/02/21

C#

リンク

[C#]最新言語仕様を使った『宣言的プログラミング』でバグが少なく可読性の高い高品質なコードを書こう - Qiita

はじめに LINQの登場後、C#は地道な進化を続け、C# 7で登場したタプルと分解、パターンマッチング、C# 8で登場したswitch式、C# 8,9で強化されたパターンマッチングなどによって、C#のプログラミングスタイルは劇的に変化しました。昔では考えられなかったようなスタイルのコードが記述可能になり、可読性やコードの安定性が飛躍的に向上しています。そのキーポイントとなるのが、「宣言的プログラミング」です。この記事では、最新のC#を使ってコードを宣言的に書く手法を紹介します。やってる人は自然とやっている事だとは思いますが、そうではない人もいると思いますので、そういう方の参考になればと願っています。宣言的プログラミングとは宣言的プログラミングとは、「どうやってやるか（how）ではなく何をしたいか（what）を書く」と良く言われますが、なんとなくあいまいです。これをもう少し具

s_ryuuki 2022/03/03

C#

リンク

[.NET]これがないとDIなんてやってられない！アセンブリスキャンによるサービスの自動登録 - Qiita

目的 ASP.NETにおけるDI(Dependency Injection)時に、ConfigureServicesで個々の型をひとつひとつ登録しているときりがないし、これが開発のボトルネックになりかねません。そこで必要となるのが、アセンブリスキャンによるサービスの自動登録です。AutoFacなどのDIコンテナでは標準搭載していますが、MicrosoftのDIコンテナでは今のところ未搭載です。また、例えAutoFacを使ったとしても、「C#でアセンブリを取得するのはあなたが考えるより難しい（Getting Assem blies Is Harder Than You Think In C#）」でも書かれているとおり、スキャン対象のアセンブリを取得するのはなかなか面倒な作業でもあります。この記事では、アセンブリをスキャンして登録対象の型を自動的にDIにサービス登録する為の適切な方法につい

s_ryuuki 2021/10/14

DI
C#

リンク

「DI使うとインタフェース地獄に陥るらしいから使いたくない」と言っていたA氏がインタフェースを使わずにDIで幸せになるまで - Qiita

「DI使うとインタフェース地獄に陥るらしいから使いたくない」と言っていたA氏がインタフェースを使わずにDIで幸せになるまでC#DIDependencyInjection依存性の注入 DIはインタフェース定義しなくても十分実用的だし、むしろそっちの方が本質だよ、という話をします。C#や.NETを使っていますが、それに限らず普遍的な内容です。インタフェースと実装に分けるとか無理。DIなど不要！中堅社員のA氏は、**「DIっていちいち実装とインタフェース分けないとダメなんでしょ？。さすがにやってられんわ」**と言って頑なにDIを導入しようとしません。 DIはテスタビリティと併せて語られることが多かった為か、A氏は「注入するクラスは基本的にインタフェース定義しましょう」という記事ばかりを読んでいたのです。インタフェースと実装を分けるとは、例えば次のような事です。 services.AddSc