ふらっと C#,C♯,C＃（初心者用） Part151

2021/05/16(日) 10:45:59.00

!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為）

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
>>980を踏んだ人は新スレを建てて下さい。>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part150
https://mevius.5ch.net/test/read.cgi/tech/1616471904/
■関連スレ
C#, C♯, C＃相談室 Part94
https://mevius.5ch.net/test/read.cgi/tech/1553075856/
■コードを貼る場合は↓を使いましょう。
https://ideone.com/
https://dotnetfiddle.net/

■情報源
https://docs.microsoft.com/ja-jp/dotnet/standard/class-libraries
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/
https://docs.microsoft.com/en-us/dotnet/standard/class-libraries
https://referencesource.microsoft.com/
・Insider.NET > .NET TIPS - ＠IT
https://www.atmarkit.co.jp/ait/subtop/features/dotnet/dotnettips_index.html
・DOBON.NET　.NET Tips
https://dobon.net/vb/dotnet/index.html

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2021/07/20(火) 18:15:30.23

ボクのお尻も固まりそうです

2021/07/20(火) 18:32:55.57

async汚染が怖いので使わない方向で

2021/07/20(火) 19:34:56.43

WPFのバインディングについて質問です。
テキストボックスに読み取り専用プロパティをバインディングしたいのですが、
プロパティの値を変更してもテキストボックスに反映されません。
調べたら、プロパティの変更を通知するイベントが無いとだめとのことだったのですが、
setterなしでに通知イベントを実装する方法は無いでしょうか。

例：
public class ViewModel
{
public int ID { get; set; }
public string Name { get; set; }
public string NameSan { get => Name + "-san"; }
}

<TextBox Text="{Binding NameSan}" />

2021/07/20(火) 19:59:24.26

誰にとっての読み取り専用なん？

2021/07/20(火) 20:08:36.24

wpfでバインドできないプロパティは
DependencyPropertyでないから
DependencyObjectを派生させる必要がある
→UserControlを作ってそこにDependencyPropertyを作成する

ってググったら出てきた

2021/07/20(火) 20:21:36.49

XAML側でNameをバインディングしてコンバーターで-san付けるかなあ

2021/07/20(火) 20:27:17.58

>>664
NameプロパティのSetterでまとめて通知すれば良い

private string _name;
public string Name
{
get => _name;
set
{
_name = value;
PropertyChanged?.Invoke( nameof( Name ) );
PropertyChanged?.Invoke( nameof( NameSan ) );
}
}

2021/07/20(火) 20:35:19.09

>>664です。
沢山の回答レスありがとうございます。
例として記入したものが不適切でしたので、訂正させてください。
実際はNamesanのgetterには別クラスから値を取得するメソッドが実装されており、
NameやIDはNamesanでは使用しないものになります。

public class ViewModel
{
　public string NameSan
　{
　get
　{ //別クラスから値を取得するメソッド}

なので、>>668様にご教示頂いた方法は使用できない形になります。

2021/07/20(火) 21:00:19.75

>>669
外のクラスだろうがやることは変わらない
外のクラスからNameSanプロパティの内容が変わるタイミングで同じように通知する
外のクラスを変更するのが出来なければタイマーで通知を出すなんて荒業も思い付いたけどいまいち

2021/07/20(火) 21:07:59.62

>>670
>外のクラスからNameSanプロパティの内容が変わるタイミングで同じように通知する
ありがとうございます。外のクラスから通知させることができるのですね。
早速試してみたいと思います。

教えてくれた皆様、ありがとうございました。

2021/07/20(火) 21:11:28.67

なんでパターン崩してイレギュラーなことしようとするんだろ

2021/07/20(火) 21:45:11.17

>>670
ちょっと訂正。忘れてた。
クラスの外からイベントを直接発生させられないから、ViewModelクラスに変更通知イベントを
発生させるメソッドを実装して、外のクラスからはそのメソッドを呼び出す必要がある。

public Class ViewModel : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
public void FirePropetyChangedEvent()
{
PropertyChanged?.Invoke( nameof( NamaSan ) );
}
}

2021/07/20(火) 22:00:21.86

>>672
その時点でこのスレには相応しくないよね

2021/07/21(水) 21:46:25.70

その外のクラスの変更通知を受け取って、自身の変更通知をだせばいいんじゃないのか
なぜわざわざ外のクラスが別クラスのメソッド呼ぶんだ？依存関係がおかしいだろ

2021/07/22(木) 09:48:14.07

>>673
イベントで実装する必要性がよく分からないんだよな
FuncやActionでよくねって思っちゃう

2021/07/22(木) 11:03:00.91

>>675
だね

Modelの値が変更されたらViewModelの値も変更してUIも更新したいってことだから
ViewModelでModelの変更通知をsubscribeしてsetter経由でPropertyChangedイベントを発生させてUIを更新すればいい
値の更新が必要にもかかわらず読み取り専用プロパティにする意味がよくわからない

2021/07/22(木) 15:01:08.94

PropertyChangedイベントを発生させれば事足りるのだが
setter経由させる意味がわからん
そのために読み取り専用を読み書きに変えるのか？

2021/07/22(木) 15:10:14.18

WPFなら仕方ない
嫌ならオワコンWPFなんか捨ててWebで仮想DOM系のフレームワーク使えば何もしなくても自動的に差分取ってくれるよ

2021/07/22(木) 15:34:51.65

>>678
>PropertyChangedイベントを発生させれば事足りるのだが

どこで発生させるの？

2021/07/22(木) 17:41:00.24

適当にはこんな感じでしょ
model.PropertyChanged += (sender, e) => {
if (e.PropertyName == nameof(model.Hoge)) {
this.OnPropertyChanged(nameof(this.Piyo));
}
};

public string Piyo => $"OK {this.model.Hoge}";

2021/07/22(木) 19:46:33.52

イベントを発生させてないじゃん

2021/07/22(木) 19:51:13.33

基本をまず理解してないなあｗ

2021/07/23(金) 21:15:00.87

PropertyChangedという言葉の意味を考えてみろ
setterにあるのが自然だろ
おまじないだよ考えなくていい

2021/07/23(金) 23:01:35.61

そのためにわざわざ読み取り専用でいいプロパティにsetter作れってか

2021/07/23(金) 23:08:52.13

>>684
よく勘違いしてる人いるけど、イベントの-edは過去分詞じゃなくて動詞の過去形
つまりプロパティが他者によって変更されたのではなくプロパティが主体なので、
setterによらず自発的に変更イベントを発生させたとしてもなんら不自然ではない

2021/07/24(土) 00:23:31.06

イベントが過去形か受動態かについては議論があるよ
全部過去形だというのは明らかに無理があるw
どっちの場合もあると思うしそれでいいでしょ。

受動態＞過去形＞完了形

一般的な使用頻度はこうじゃないかな。
しばらく前からイベントに普通の名詞形を使う命名の仕方もあるよね

2021/07/24(土) 00:26:07.51

>>687
https://docs.microsoft.com/ja-jp/dotnet/standard/design-guidelines/names-of-type-members#names-of-events

2021/07/24(土) 00:33:52.24

>>688
それはあくまでガイドライン。
実態の話をしてるんでしょ。

例えばそこのページに出ているDroppedDown、
dropは自動詞だと思うので過去形だという主張はちょと無理がある

2021/07/24(土) 00:36:42.84

長々と何やってんだこいつらは

2021/07/24(土) 00:55:30.71

>>689
droppedは過去形でよく使わんか？
an apple dropped down.とか
stock price dropped.とか。

2021/07/24(土) 01:44:28.78

よく勘違いしてる人いるけどwww

2021/07/24(土) 01:47:50.50

その労力でドキュメント書けよと

2021/07/24(土) 02:04:43.55

何したいのかよくわからんけど
getterしか必要ないってことはそもそも画面に表示する必要ないプロパティじゃないの

2021/07/24(土) 02:16:18.66

イミフ
値に単位でも付いてんじゃん？

2021/07/24(土) 02:31:41.54

>>691
何を言っているのか意味がわかんないけど、自動詞って言葉の意味は分かる？
dropしたのはDroppedDownイベントを発生させるオブジェクトではないよね？
イベントを発生させるオブジェクトはdropしたんじゃなくて「された」んだよw

もちろん「何かが落ちた」という現象を通知するイベントなんだと強弁することもできるが、
これ言ってて苦しいでしょ（笑）不自然で無理矢理すぎる。
受動態だって考える方が100倍自然だ。

Clickedイベントとかも同じ。
これが過去形ならButtonが自分で自分をクリックしたのかとw
お前はクリックしたんじゃなくてされたんだろうがとw

2021/07/24(土) 02:49:48.99

どうでもいいことをｗ

2021/07/24(土) 07:33:48.35

続きは議論スレでどうぞ。

ふらっと C#,C♯,C＃（議論用） [無断転載禁止]©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1469538912/

2021/07/24(土) 09:11:25.75

>>696
自動詞わかるよ？

なんで自制を使うかって理由が抜けてるんだと思う。
ネイティブにとってもそこはMSの方針いけてねえよなって思うところかもしれんのだと思うんだけど、MSはBeforeClickとAfterClickとかそういう接頭語を使ってイベント発火順を表して欲しくないんよ。
なので、Clickのあとに起こるイベントはClickedなんよ。
Click→Clicking→Clickedになる。

2021/07/24(土) 09:34:03.83

NCが無いぞ

2021/07/24(土) 10:12:44.82

>>694
ViewModelでの話に限って言うと
setterを持っているってことはViewから入力があるという含意がある
（もちろんケースバイケースでそうでない設計にすることもある）

で、例えばViewのラベルで現在時刻表示するためにViewModelにNowTimeプロパティを用意したとして
Viewからの入力はないんだからsetterを用意するのはおかしいよね、ということ

2021/07/24(土) 11:05:01.44

>>698
誘われてあっちを久し振りに読んでみたけど、ここよりも有意義なことが書いてある気がしてならない。

2021/07/24(土) 12:26:37.04

>>701
現在時刻は変化してくんだからprivateなセッターで値を更新して、プロパティ変更イベント発生させればいいんじゃないの？

2021/07/24(土) 12:40:41.42

>>701
>setterを持っているってことはViewから入力があるという含意がある

ないよ
外部から呼ばれたくなければprivate/protectedなsetterを使う

現在時刻のような呼び出しのたびに変化するような値は一般的にプロパティにすべきじゃないよ
(DateTime.Nowとかあるけど、あれはMSも間違いだと思ってるらしい)

2021/07/24(土) 12:42:42.49

別にそれでもいいんだけど
現在時刻そのものはDateTime.Nowでとるじゃん（これがModelに相当する）
わざわざViewModelにDateTimeのフィールド置いたりとかする必要がない
ViewModelは単にDateTime.Nowを返すgetterを持つだけで充分
setter書いても実際には何もsetしないとか違和感バリバリだし

2021/07/24(土) 12:46:48.97

>>704
> (DateTime.Nowとかあるけど、あれはMSも間違いだと思ってるらしい
ソースは?

2021/07/24(土) 13:18:24.45

もとの話は他のクラスのプロパティから導出されるプロパティって話だったんだが

2021/07/24(土) 13:23:10.38

>>705
それでもいいじゃなくて、どうクラスを設計するか
取得した時点でモデルプロパティ値が更新されたと見なす仕様なのか、リアルタイムで更新する仕様なのか
単に現在時刻をとれればいいのであれば、それはプロパティじゃなくてメソッドだし、プロパティ変更イベントを用意する必要もない

2021/07/24(土) 13:39:01.39

DateTime.Nowは設計失敗の産物って話、俺もどこかで読んだ記憶があったんだけど
おおもとのソースは書籍だったみたいだ
ググったら個人ブログの感想でこんなのが引っかかった
https://ufcpp.wordpress.com/2009/12/27/net-%e3%81%ae%e3%82%af%e3%83%a9%e3%82%b9%e3%83%a9%e3%82%a4%e3%83%96%e3%83%a9%e3%83%aa%e8%a8%ad%e8%a8%88/

2021/07/24(土) 13:48:21.00

海外のクソライブライブラリ使うとたまにそういうレベルでメソッドになったりプロパティになったり
非常に邪魔くさい

DateTime.NowがDateTime.Now()になったりDateTime.GetNow（）になったりDateTime.GetInstance.Nowになったり
コロコロコロコロ変えてくる

ドキュメントが整備されてないからインテリセンスで推測して変更するしかない

2021/07/24(土) 14:41:03.27

>>702
向こうでやると初心者用スレに書かない人が現れて論破されちゃうから行きたくないらしいよ
ここで議論してる人はその程度って事

2021/07/24(土) 19:53:22.67

>>701
その含意はない
XAMLのModeプロパティでOneWayとか指定するようになってるし

2021/07/24(土) 20:51:57.91

俺ならModelの方にINotifyPropertyChangedを実装して、VMでは
ReadOnlyReactivePropertyで変更通知を中継するな

2021/07/25(日) 17:48:33.79

アドバイスを頂きたいです。
簡単なCRUD機能を持ったコンソールアプリがあり、EntityFrameworkを使用してSQL Serverとのやり取りを行っています。
このSQL Serverのデータベースを年毎に個々に持ちたいという要件が出てきました。
テーブル構成等は全く同じで2020年のデータベース、2021年のデータベースをそれぞれ立てるという形です。

ただ、毎年この作業の対応は出来ないので、コマンドを叩くだけのような自動化をしたいと考えております。
理由として社内の事情によりvisual studioを使用する事が難しい点があります。
その為、アプリ側でDBとの接続情報を変更して発行しなおす事がハードルが高いため、可能であれば自動化したいです。

データベースの作成はSQL文を使用すれば良いと思うのですが、EntityFrameworkを使用しているアプリ側への対応として、「接続するデータベースが変更された場合」という部分はどのように対応してよいか分かりません…。

CodeFirst、ModelFirstどちらの場合でもデータベースの変更に対応するにはやはりプログラム側で変更するしかないでしょうか？
データベースを年毎に分けた場合、過去のデータを参照したい時に年毎のデータベースそれぞれのDbContextの情報を作成しないと行けないと考えるとやはり自動化は無理でしょうか…

当方素人レベルなので良い案も浮かばず、何か少しでもアドバイス頂きたいです…。
長文大変失礼しました。

2021/07/25(日) 17:54:33.09

sqlserverで1年に1回ジョブながせばいいのでは？
今年分のdbは常に'hoge'って名前にして、1/1　0:00にhogeをデタッチして名前変更。
でhogeを新規作成

2021/07/25(日) 18:11:58.13

>>715
ありがとうございます。
通常使用するのは「hoge」固定とし、年が変わるごとに「hoge2020」「hoge2021」のように名前を付けて別物として扱うということですよね。

私もこれなら行けるかもと考えていたのですが、例えば過去のデータを参照したい場合に「hoge2020」「hoge2021」の情報をアプリ側が所持していないので参照出来ないのでは…と思い悩んでいました…。(先程コンソールアプリと記述してしまいました、すみません。正しくはフォームアプリです)

2021/07/25(日) 18:27:49.79

変更した情報をhogeのテーブルに持ち、クライアントへ渡しては？

hogeのConnStrInfoテーブル

ID,　db_name, year
1,　hoge_2018,　2018
2,　hoge_2019,　2019
3,　hoge_2020,　2020

これをクライアント側で取得し、動的に接続先を切り替える。
efだとConnection Stringをこねくり回すのはめんどいかもしれないけど
他に方法が思い浮かばない。

2021/07/25(日) 18:42:30.26

>>714
DBが分かれていて、別のDBに接続するときに接続情報を切り替えるのは当然だと思うけどなんでそれがダメなの？

2021/07/25(日) 19:28:19.50

>>717
ありがとうございます。
こんな方法思いつきませんでした。
知識が乏しいので、私にはかなり難しそうですがプログラム側で変更出来ないならDB側で工夫するしかないですね。

>>718
アプリはEntityFrameworkを使用し、既存のデータベースからモデルを構築しています。
年毎にデータベースが増えたとしてもvisual studioの機能を使用し、データベースの構造をモデル化すれば良いのですが、諸事情によりvisual studioの利用が難しい環境ですのでプログラム側を変更しなくて済むような別の方法を探しています…。
回答になってなかったら申し訳ありません…。

2021/07/25(日) 20:53:07.93

それってテーブル設計に変更があったら過去のデータベースも変更するの？
そこ詰めといた方がいいよ

2021/07/26(月) 03:27:45.68

データベースが増えても構造が変わらない限りモデルは増えないけどどんなイメージをしてるのか気になる

2021/07/26(月) 03:31:43.27

新しいテーブルに既存のテーブルから正規化しつつ移行ってパターンで1回地獄見たな。
該当の既存のテーブルを、協力会社の古い基幹システムが使ってて、そっちが動かなくなった。

2021/07/26(月) 09:47:45.98

普通に作ってればＤＢの接続情報をプログラム内に固定でもってることなんてないと思うが

つか年度ごとに別ＤＢ作るとかそもそもの発想がもう普通じゃないかｗ

2021/07/26(月) 11:04:48.50

まあソースベタがきは確かにないやろな

色々冷静な判断が出来ない現場なんだろう、知らんけど

2021/07/26(月) 11:09:22.19

もしかしてパーティショニングの事を言ってる可能性。

2021/07/26(月) 11:11:01.52

年度毎にデータを残しておいていつでも出せるようにしてほしいみたいな客の言葉を
常識的なシステム設計を理解していないバカが鵜呑みにしちゃった結果だろ
ギョウムシステムにはよくあること

2021/07/26(月) 11:54:28.60

市販の会計ソフトだと年次ごとデータベースを分ける作りにしてるのはよくある

旧年度のDBはそのままにして新年度だけDB構造を変更できたり
確定処理後は読み取り専用にするのをアプリ層じゃなくDB層でできたりと
メリットもあるので一概に否定される考え方でもないと思う

2021/07/26(月) 12:38:50.17

イベントソーシングでいいじゃん

2021/07/26(月) 13:14:31.91

>>728
イベントソーシングはスキーマ変更の問題を解決しない
それどころか過去全期間に渡る全データのマイグレーションというとてつもなく面倒な作業となる

2021/07/26(月) 13:15:54.39

>>729
何言ってんだ？

2021/07/26(月) 13:18:18.35

>>730
知らんがな
イベントソーシングで何がどう解決するのかお前が説明しろ

2021/07/26(月) 13:31:24.51

イベントソーシングなら過去のデータを全てそのまま維持しつつ年度ごと、それどころかあらゆる変化に対応可能
アペンドオンリーなので過去データは最初から読み取り専用
年度ごとにデータベースを分けるなんて間抜けなことはしなくていい

2021/07/26(月) 14:32:10.50

スキーマ変更に対して取りうる戦略ってのはイベントソーシングでも基本的に同じ

読み取り専用にする話はイベントソーシングで言うと
確定処理後に過年度のイベントが入ってこないようにしたり
入ってきてもプロジェクション時に必ず除外するようなアプリを通す必要がある

アプリ層で処理するって意味では年度別にデータベースを分けずに各データに年度をもたせた場合と同じ

2021/07/26(月) 15:09:24.98

この業界わけのわからない横文字技術で解決することっていっつも皆無だよね
単に下駄履かせてイキってるだけ

2021/07/26(月) 15:51:35.56

>>733
>スキーマ変更に対して取りうる戦略ってのはイベントソーシングでも基本的に同じ
わからない
RDBではデータモデルの変更が発生すればスキーマを変更する
イベントソーシングはデータモデルの変更が発生してもアプリケーションを変更するだけ
つまりイベントの再生方法が変わるだけでデータレイヤは永遠に同じ

>読み取り専用にする話はイベントソーシングで言うと
>確定処理後に過年度のイベントが入ってこないようにしたり
>入ってきてもプロジェクション時に必ず除外するようなアプリを通す必要がある
イベントソーシングでは過去の状態を再生するにはタイムスタンプでフィルタするだけ
過年度の変更イベントが入っても過去の状態の再生には影響しない

>アプリ層で処理するって意味では年度別にデータベースを分けずに各データに年度をもたせた場合と同じ
単にタイムスタンプでフィルタするだけなのでアプリ層の仕事は存在しない

2021/07/26(月) 16:18:53.38

そんな夢みたいな仕組みがなんのしがらみもなく完璧に動作するならみんな使ってるよ…

2021/07/26(月) 16:34:40.70

完璧に動作するんだけど大きなパラダイムシフトだから精神的抵抗orマイグレーション抵抗があってみんな食わず嫌いしてるだけ

2021/07/26(月) 16:54:08.24

馬鹿なんだろうなあきっと

2021/07/26(月) 16:55:34.22

>データレイヤは永遠に同じ
イベントソーシングでは後からのスキーマ変更はすなわち意識高い系アーキテクトにとっては屈辱的な設計の破綻なので、
そうならないように属性を全部JSON型の列に突っ込むような緩いスキーマを採用する場合があるってだけだ
引き換えに失うものはC#プログラマならよく理解してるだろう
もちろんちゃんと型を付けて真面目にDBを使う選択もあって、その場合はよくある普通の取引記録テーブルと変わらん
スキーマvsスキーマレスの違いであり、イベントソーシングとは直接関係ないよ

2021/07/26(月) 17:00:20.93

>>738
自己紹介？

2021/07/26(月) 17:03:55.87

>>739
ビジネス要件は日々変化するのでスキーマ変更を屈辱と感じるのは古臭い考え方のおじさん達だけだよ
変化に柔軟に適応するために最適化した進化と考えればいい
なおデータレイヤがスキーマレスだからといってモデルがタイプレスになるわけではないことは知っておいたほうがいい
C#や類似の言語が持つ静的型の堅牢性はESでも依然として完全に発揮されるので安心していいよ

2021/07/26(月) 17:12:24.77

そうかなあ
スキーマレスだとせっかくのnull許容参照型もあまり役に立たなくなるし、
おかしなデータが混入しててデシリアライズ時に型違いで落ちるとか日常茶飯事だったよ
マイグレーションによる停止が許容できるなら断然スキーマがある方が楽よ

2021/07/26(月) 17:23:29.78

>>742
さっきも言ったようにESでモデルの静的な型安全性が損なわれることはない
notnull/nullableは依然として有効だよ
再生時に型違いで落ちるのが日常茶飯事というのは何を言ってるのかわからないね

2021/07/28(水) 15:11:51.63

初歩的な質問でごめん
EntityFrameworkで2つのテーブルをjoinするやり方を調べてると下のコードみたいに結合した結果を作るように書いてたのね

(book, category) => new{
Title = book.Title,
Category = category.Name,
PublishedYear = book.PublishedYear
}

もしbookテーブル、categoryテーブルが例えば100列ずつあって結合後に全要素取得したい場合はnew以降に全カラム分記述しなきゃいけない？

2021/07/28(水) 17:18:49.56

いけないことはない

2021/07/28(水) 17:28:01.17

var q = db.Books.Join( db.Categories, o => o.id, i => i.id, ( o, i ) =＞ new { Book = o, Category = i } );
foreach(var row in q)
{
　int bookId = row.Book.id;
　int categoryId = row.Category.id;
　：
　：
}

まぁ不要なカラムを含んでいる分、使用メモリも増えるが。
生産性優先なら上記のように書くことも多々あり

2021/07/28(水) 19:36:49.49

>>746
ありがとう
確認だけど、この部分で全要素をqに格納が出来て

var q = db.Books.Join( db.Categories, o => o.id, i => i.id, ( o, i ) =＞ new { Book = o, Category = i } );

欲しい要素がある場合は後から個別に参照するって感じだよね

foreach(var row in q)
{
　int bookId = row.Book.id;
　int categoryId = row.Category.id;
　：
　：
}

LINQ難しい…

2021/07/28(水) 20:04:32.82

テーブルの結合て、モデルの結合だよな
モデルの設計をミスってるとしか思えんのだが

ほんとにテーブルを結合したいなら生ＳＱＬ流せばいいんじゃね

2021/07/28(水) 20:37:20.88

>>747
そう。
Linq文は横に長くなりがちなので、一時変数は極力短くすることが多いのも難しく感じる要因かな。
やってるのはただのinner join

もうちょっと丁寧に書くと
using(var db = new HogeContext() )
{
　// 欲しい情報
　string bookName;
　int bookPrice;
　string categoryName;

　// クエリ生成
　var query = db.Books.Join( db.Categories, outer => outer.category_id, inner => inner.id, ( outer, inner ) => new { Book = outer, Category = inner } );

　// 実際のDB接続とクエリ実行はforeach文に到達したとき
　foreach(var row in query)
　{
　　bookName = row.Book.name;
　　bookPrice = row.Book.price;
　　categoryName = row.Category.name;
　　：
　　：
　}
}

情報取得だけならAsNoTracking()つけたりするから、さらに横に長くなる。

2021/07/28(水) 23:03:49.99

こんなトンチみたいなことするより
サクッとSQLでええわってならんの？

2021/07/28(水) 23:47:01.98

スマートに書けませんか？系のスマートは究極的には人それぞれなものでね…

2021/07/29(木) 11:05:49.23

EF使うようになってから明示的なJoinなんて滅多にやらないしな
今回のもdb.Books.Include(x =>x.Category)でいいし

2021/07/29(木) 12:18:33.25

>>749
分かりやすくて助かるありがとう

EFで取得した値がnullかどうかをチェックってどうしてるの？
生のSQL書くやり方だと取得した取得したDataReaderをループで回して

while(reader.Read() )
{
for(var i = 0; i <= 10; i++)
{
if(Convert.IsDBNull(reader[i])))
{
testList[i] = 0;
}
else testList[i] = reader[i]
}
}
↑みたいにチェックしてnullだったら0埋めとかやりたい処理を書くんだろうけど、EFで取得した値だと上で教えてくれたように

foreach(var row in query)
　{
　　bookName = row.Book.name;
　　bookPrice = row.Book.price;
　　categoryName = row.Category.name;
　}
ループで回してもrow.Book.nameみたいに個別にアクセスしないといけないからnullのチェックはそれぞれの要素に対してするの？
わかりにくくてごめん

2021/07/29(木) 12:47:21.43

WPFでcanvasに図形が追加されるたびにその状態を保存してUndoRedo機能を作りたいです
stack<t>にcanvasを入れれば実装できると考えていたのですが出来ませんでした
stackの中身を見てみるとcanvasが全て最新のものになっていました
理想
①図形追加
→stack1 canvas(図形一個だけ)
②図形追加
→stack1 canvas(図形一個だけ)
→stack2 canvas(図形2個)
③図形追加
→stack1 canvas(図形一個だけ)
→stack2 canvas(図形2個)
→stack3 canvas(図形3個)
実際
①図形追加
→stack1 canvas(図形一個だけ)
②図形追加
→stack1 canvas(図形2個)
→stack2 canvas(図形2個)
③図形追加
→stack1 canvas(図形3個)
→stack2 canvas(図形3個)
→stack3 canvas(図形3個)

this.canvasをstackにpopで格納しているのですが恐らく参照型になっている(？)のかと思います
どうすれば解消されるか教えてください

2021/07/29(木) 13:19:29.67

>>754
stack2を作る時に、
var stack2 = stack1;とすると同じインスタンスを参照するのでstack1の追加が反映される
var stack2 = new stack(stack1);とすると別のインスタンスを参照するので反映されなくなる

という話であってるよね

2021/07/29(木) 18:55:32.43

分からない事を相手に伝える能力って大切だよな。

2021/07/29(木) 19:16:32.82

それができる人って、5chで質問しなきゃならんような事態には陥らないんだよね。

**>>754です** (ﾜｯﾁｮｲ 1a36-SEfg) · 2021/07/30(金) 00:50:25.37

stackのインスタンスは1個だけです

Stack<Canvas> stack = new Stack<Canvas>();で宣言して
①canvasに図形追加後にstack.Pop(canvas)
→stackの中身1個目(図形一個だけ))
②canvasに図形追加後にstack.Pop(canvas)
→stackの中身1個目(図形一個だけ)
→stackの中身2個目(図形2個)
③canvasに図形追加後にstack.Pop(canvas)
→stackの中身1(図形一個だけ)
→stackの中身2(図形2個)
→stackの中身3(図形3個)

少し書き直しました
これが実現したことです

**>>754です** (ﾜｯﾁｮｲ 1a36-SEfg) · 2021/07/30(金) 00:52:16.98

連レス申し訳ないです
PopではなくPushでした

2021/07/30(金) 02:25:15.43

stackにcanvasをpushしたあと、
そのcanvasは再利用せず、newして作り直してる？

2021/07/30(金) 05:37:39.20

まず「値型参照型 C#」でググってみよう

**>>754です** (ﾌﾞｰｲﾓ MM9a-SEfg) · 2021/07/30(金) 10:43:57.97

>>760
Redo()｛
Canvas Newcanvas = this.canvas;
stack.Push(NewCanvas);
｝

してます