- 1 名前：デフォルトの名無しさん mailto:sage [2019/05/16(木) 07:52:32.39 ID:8fOYIMEO.net]
- Windows Presentation Frameworkについて語るスレ。
前スレ
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part22
https://mevius.5ch.net/test/read.cgi/tech/1513175747/
関連スレ
Windows 10 UWPアプリ開発 Part 2
mevius.2ch.net/test/read.cgi/tech/1499658092/
コードを貼る場合は以下のサイトの利用をお勧め。
run codeのチェックは外しておきましょう。
ideone.com/
- 182 名前：デフォルトの名無しさん mailto:sage [2019/06/12(水) 08:15:06.43 ID:1sqooHn/.net]
- お前がメンテナになるんだよ
- 183 名前：デフォルトの名無しさん mailto:sage [2019/06/12(水) 08:57:44.10 ID:gBdzPl5F.net]
- 金出しゃいくらでも居るよ
技術者を安いおちんぎんでこき使わないで
- 184 名前：デフォルトの名無しさん mailto:sage [2019/06/12(水) 17:09:04.38 ID:lPa5yFg1.net]
- 技術者不足なのか足りてるのか分からん業界だ
- 185 名前：デフォルトの名無しさん mailto:sage [2019/06/13(木) 20:13:48.97 ID:Qp/i0hmX.net]
- core3いいじゃん
これで少し手直ししたらlinuxにwpfもっていけるってことなのかい
- 186 名前：デフォルトの名無しさん mailto:sage [2019/06/13(木) 20:59:16.46 ID:vbUZdfMk.net]
- 残念ながらWPFやWinFormsは.NET CoreでありながらWin限定
WPFは大部分がC++/CLIで書かれているしWindows APIに依存しまくってるから、
まずはそれを全てポータブルな形に再実装しなければならない
百人月クラスの壮大なプロジェクトだ
- 187 名前：デフォルトの名無しさん mailto:sage [2019/06/13(木) 21:15:12.81 ID:sfQNEli4.net]
- 100人月で済むならやりゃいいじゃん
壮大なプロジェクトって少なくとも１桁違うやろ
- 188 名前： mailto:sage [2019/06/13(木) 21:31:32.83 ID:RglcOoNZ.net]
- >>180
一桁はおろか、二桁＝1万人月くらいは必要じゃないかな…
- 189 名前：デフォルトの名無しさん mailto:sage [2019/06/13(木) 21:32:10.18 ID:09qLCJE0.net]
- MS社員の100人月ならドカタのサグラダファミリアだな
- 190 名前：デフォルトの名無しさん mailto:sage [2019/06/13(木) 21:41:06.34 ID:Br82W2pC.net]
- そもそもポータブルなGUIに無理がある
swingの様になりたいのか
- 191 名前：デフォルトの名無しさん mailto:sage [2019/06/13(木) 22:01:08.10 ID:k5DFsQwe.net]
- C++/CLIって久しぶりに聞きましたね
もう聞くことはないと思ってた
- 192 名前：デフォルトの名無しさん mailto:sage [2019/06/13(木) 23:20:07.43 ID:sfQNEli4.net]
- そもそもWPFなんだからWindows限定でよくね？
- 193 名前：デフォルトの名無しさん mailto:sage [2019/06/13(木) 23:25:38.96 ID:CND6SLBs.net]
- WPFはフルスクラッチでUIを描画してるから、アーキテクチャ的にはむしろWin限定にするほうが不自然
- 194 名前：デフォルトの名無しさん mailto:sage [2019/06/14(金) 21:47:31.30 ID:nRSl3ZvU.net]
- >>179
そうなん…
Win専用ならCoreにしても…
C++/CLIはたまに使う
- 195 名前：デフォルトの名無しさん mailto:sage [2019/06/15(土) 09:19:09.60 ID:Ga3aXpPN.net]
- Chromium+AspNetCore+Blazor
次世代の.NET系デスクトップフレームワークはこうなる
- 196 名前：デフォルトの名無しさん mailto:sage [2019/06/15(土) 09:27:21.19 ID:6PSH/Imj.net]
- 過剰なクライアントサイド志向に対する最近の揺り戻しのムードの中で、サーバーサイドBlazorだけならワンチャンあったかもね
Blazorを正式なプロダクトとして推していくと決めた時点で、クライアントBlazorは廃止してサーバーサイド一本にするべきだった
Blazorといえばwasmのオモチャというイメージを払拭できない限り普及はない
- 197 名前：デフォルトの名無しさん mailto:sage [2019/06/15(土) 09:42:50.74 ID:Ga3aXpPN.net]
- SSRはもとはクライアントでしか動かないjsが鯖で動くすごいって技術
だからjs以外の言語だとSSRはなにも真新しさはない古典的な技術だ
なのでBlazorでサーバーサイドをやる意味はない(api、MVC、Pagesで十分)
クライアントで.NETを動かすことに意味がある
- 198 名前：デフォルトの名無しさん mailto:sage [2019/06/15(土) 09:49:12.97 ID:p9QrGiGS.net]
- Blectron的なやつのことを言いたい？
- 199 名前：デフォルトの名無しさん mailto:sage [2019/06/15(土) 10:13:25.41 ID:Ga3aXpPN.net]
- >>191
Blectronは知らないがElectronの.NET版という意味ならまさにそうだな
ググったらもうすでに同じ発想で取り組んでるOSSユーザーが少なからず居たから
もう暫くしたらBlazorでクロスプラットフォームデスクトップアプリが実用
- 200 名前：化するんじゃないかな []
- [ここ壊れてます]
- 201 名前：デフォルトの名無しさん mailto:sage [2019/06/15(土) 10:33:45.61 ID:p9QrGiGS.net]
- >>192
Blectlonでググったかい？
- 202 名前：デフォルトの名無しさん [2019/06/15(土) 15:17:17.19 ID:xT5QU/B2.net]
- 新卒で入った会社（５年前）がWinFormだったな。今も多分そう。
今はWindows用のコード書くことがなくなってしまったが、
あれはあれで生産性高いと思うわ。業務アプリだとデザイン性いらないし
- 203 名前：デフォルトの名無しさん mailto:sage [2019/06/15(土) 15:30:24.49 ID:RNWBuCRz.net]
- WPFも主ターゲットは業務向けだけど、日本のITドカタが業務システムと聞いてイメージするオーダーメイドなシステムとはだいぶ違う
米国では早くからシステムのパッケージ化が進んでいて、
パッケージベン�
- 204 名前：_ーにとっては一つ作れば多くの客に売れるから多くの開発リソースを投資してリッチなUIを作ることができる
そういう事情を踏まえて誕生したのがWPFなんだよ
日本でも近年は脱オーダーメイドが進みつつあるけど、既にリッチクライアントの時代が終わってSaaSになっちゃったからWPFの出番は来なかった [] - [ここ壊れてます]
- 205 名前：デフォルトの名無しさん mailto:sage [2019/06/15(土) 16:35:30.94 ID:hWID9DJj.net]
- 日本の業務アプリには御託並べるWPFプログラマは不要。
黙々と作業に徹するWinformコーダーが居ればよい。
- 206 名前：デフォルトの名無しさん mailto:sage [2019/06/15(土) 17:08:33.15 ID:RjknjEo7.net]
- 業務にアクティブ要素、動的要素なんていらないからな。
コントロール全部並べてあって使えないところは無効化されてるだけでいい。
状況によって位置が変わるのをすげー嫌がる。操作ミスが増えるだけ。
- 207 名前：デフォルトの名無しさん [2019/06/16(日) 01:46:25.54 ID:AXRRwyW/.net]
- バインドしてみたけど、まったくメリットが分からん...
marikooota.hatenablog.com/entry/2017/05/30/002059
とか、↓の方が簡単だと思う。
-- xsml --
<StackPanel>
<TextBox x:Name="tb1"/>
<Button Click="btn_Click">Count Up!</Button>
</StackPanel>
-- cs --
int count = 0;
private void btn_Click(object sender, RoutedEventArgs e)
{
count++;
tb1.Text = count.ToString();
}
誰か、バインドのメリットをアホな俺に教えて下さい...
- 208 名前：デフォルトの名無しさん [2019/06/16(日) 01:47:53.07 ID:AXRRwyW/.net]
- >>198
空白文字消されるんですね; 読みにくくてすみません💦
- 209 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 03:49:25.26 ID:3DdY3936.net]
- バインドの最大なデメリットは天才と無職しか使いこなせないこと。
- 210 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 09:03:33.98 ID:muf2QdNo.net]
- >>198
あなたの作りたいツールがボタン押したら
カウントアップするだけの機能だけでよいなら理解する必要はない
でもたいていはそのテキストボックスには外部ファイルを読み取ったり、
データベースからデータをとってきて、集計したり加工した値が入るはずだ
その時にはbtn_clickのコードは肥大化して容易に1,000行を超える
その時には関数に切り分けたりすることを覚えるだろう
さらに進んでいくと、画面を凝ったデザインにしたくなったりユーザーの入力値を検証したくなったりする
そうすると画面のデザインを少し変えただけなのに
うまく動かなくなったりコンパイルエラーを起こすようになってきた
そこで画面は画面だけにしたほうが改修がしやすかったり、
デザインの得意な人にそれを任せることができるようになってくる
システムは機能や役割ごとに適切に分離していたほうが将来的にメリットがあり、
バインディングはそれを実現する仕組みの一つだ
- 211 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 10:07:34.99 ID:X9An2SCt.net]
- 三行で
- 212 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 10:11:25.65 ID:X9An2SCt.net]
- バインディングは逆に手順が可視化されないのが弱点
よくわからないけど動いていればいいならバインディング
そこまでしっかり自分で制御したいなら通常のコードで
- 213 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 10:14:27.54 ID:yX0oMZwq.net]
- 手順の管理は量が増えると難しくなってスケールしないから
そもそも手順気にしなくていいように宣言的プログラミングしようぜってなったんだよ
ちっぽけなアプリ作るだけなら好きにすればいいさ
- 214 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 10:14:39.65 ID:9Kn5GUQ/.net]
- ドヤ顔したいならバインディング
- 215 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 10:22:58.12 ID:X9An2SCt.net]
- バインディングにも弱点がある
相互関係で値が決まるときにその相互関係を結局人間が追わな�
- 216 名前：ｭてはならない場合が出てくる
その時に非常にバグが取りにくい
それでFBはMVVMを捨てた [] - [ここ壊れてます]
- 217 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 10:24:41.66 ID:X9An2SCt.net]
- スケールと言うけど小規模ならバインディングで対応可能だろうけど
それを超えるとまあ無理だろう
- 218 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 10:30:24.72 ID:yX0oMZwq.net]
- 手続き的だと非同期処理も非常に弱い
今の時代非同期が無いということはまずない
非同期処理ではやはり宣言的プログラミングが強い
手順すなわち処理の順番に依存すると非同期処理は急激に難しくなる
- 219 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 10:33:01.62 ID:X9An2SCt.net]
- 従来型はスケールしないと言うけど世間の大規模プロジェクトはほぼ100%
従来型（手続き型）で作られているだろう
手続きが書いてあればツールと人手を使えば解消のめどはつく
宣言的な組み合わせの場合はロジックをすべて脳に入れて考えなくてはならないので
大きくなればなるほど人間が追いつかないと思う
逆にバインディングで大規模プロジェクトが今現在も使われているとは思えない
- 220 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 10:34:56.59 ID:X9An2SCt.net]
- 人間が追い切れない場合は実行してデバッグしかないけど
それがまたバインディングの場合はやりにくい
- 221 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 10:36:05.79 ID:yX0oMZwq.net]
- >>209
スケールしないのを金と人数に物を言わせて無理やり作った
それが従来型の大規模開発だな
スケールはしてないんだよ無理してるだけで
脳に入れなきゃいけないことが多いのは手続き的なほう
なぜなら手続==処理の順番に結果が依存するから
長い処理を扱うときに最初から最後まで手順を頭に入れてなければいけない
- 222 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 11:36:30.06 ID:0yrhG5qH.net]
- 画面単位で独立したロジックを記述してDBのみ共有する従来のスタイルなら余裕でスケールするよ
WPFは頭のいいアーキテクトがトップダウンでスマートな設計をするスタイルには適している
MSのプロダクトは基本そうやって作られている
一方、従来のバカでもスケールするスタイルで作ろうとするとWPFはフリーダムすぎて無茶苦茶になる
- 223 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 12:48:19.67 ID:BOJP8Jll.net]
- そういうけどできてから10年以上立つけど
そんなに大規模のプロジェクトでWPFが使われてるような形跡がない
webでもMVVMは中規模から小規模向けで大きくなると使い物にならないという評価
- 224 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 12:56:44.07 ID:35twkBI3.net]
- >>213
っVisual Studio
- 225 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 12:59:52.96 ID:6qqET37p.net]
- 大規模で使い物にならなくなるのは、学習できない月収14万円のコーダーばっか集めてるからやろ
- 226 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 13:00:12.87 ID:Fx7TO0Mh.net]
- 大規模な画面アプリなんてあんの？
普通サブシステム単位とかで実装別れると思うけど
- 227 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 13:32:34.96 ID:yX0oMZwq.net]
- >>212
それは別の意味でスケールしない
DB処理にビジネスロジックが蔓延してメンテナンスコストが跳ね上がる
実行時パフォーマンスも悪い
- 228 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 14:00:08.42 ID:uPzprWkd.net]
- >>216
サブシステムで数百画面とかのシステムもありますので…
- 229 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 14:11:05.99 ID:UANb65jp.net]
- DBとはバインドするのは良くて、画面とのバインドは良くないという論調？
大規模な画面改修を想定しない限り、画面要素のバインドは良い事無いと思う。
作り変えるのが前提のプロトタイプならメリット有るだろうね。
レジに支払い方法追加するみたいに、旧来のロジックはそのままでレイアウトが変わるならバインディングも有効だろうね。
- 230 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 16:05:42.44 ID:X8m3/+hI.net]
- >>219
one-way binding(射影)なら良いと思う。
個人的には当初MVVMの利点と言われていた「View(UI)のすげ替えが楽」なんてのは幻想で、
「自動テストが書きやすい（手動によるE2Eテストを減
- 231 名前：らせる）」というほうに重きをおくべきだと。 []
- [ここ壊れてます]
- 232 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 16:06:40.32 ID:6qqET37p.net]
- >>220
確かにテストはめっちゃ楽だわ
- 233 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 17:08:33.07 ID:X8m3/+hI.net]
- そう、だから自動テストという意味で >>198 を考えると、
btn_Click()イベント内部では"tb1"という他人のControlオブジェクトへ直接アクセスしている。
したがって"tbl1"Controlの存在無しに実行することができないから自動テストを書くのが困難になる。
これを、
・画面に表示されている値と常に一致しているカウント変数、という概念（＝データバイディング）
・実際にカウントアップする処理（＝ビジネスロジック）
・カウントアップするきっかけ（＝イベント or コマンド）
に分けて考えることでビジネスロジックの自動テストを書くのが容易になる、というのがMVVMのメリット。
- 234 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 18:25:01.50 ID:3DdY3936.net]
- >>212
WPF登場以降、MSのアプリ、ツールに一貫性がなく碌に使われずに開発が放棄され、
サポートしきれずオープンソース化される理由はそこにあるのですね。
- 235 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 19:37:59.62 ID:G7NVDdhd.net]
- >>223
OSS化=サポートしきれない
じゃねーだろ…どんな思考してんだよ
- 236 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 20:16:09.10 ID:wZzXbGgB.net]
- 煽りたいだけだろ、スルーしとけ
- 237 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 20:45:27.52 ID:3DdY3936.net]
- >>224
オープンソース化の経緯も知らずに何頓珍漢なこと言ってんだよ。
プレミアサポートが碌に質問に答えれなくなってる現実まで知らないとか、
MSと契約してないか、開発してないかのどちらか。
- 238 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 20:46:53.30 ID:/vSSiNTa.net]
- つまりwinformsもサポート出来なくなったと
- 239 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 21:20:01.01 ID:G7NVDdhd.net]
- >>225
ごめんキチガイに触ってしまった
- 240 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 21:24:45.01 ID:C3V1csoe.net]
- >>226
Microsoftの中の人ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
- 241 名前：デフォルトの名無しさん [2019/06/16(日) 21:30:04.16 ID:GzHLSBJo.net]
- 内容はともかく >>224の言い方も若干煽り入ってるし、ムキになる方もガキ
- 242 名前：デフォルトの名無しさん mailto:sage [2019/06/16(日) 21:32:29.36 ID:WJsnIQ8z.net]
- ガキ同士仲良くしてどうぞ
- 243 名前：デフォルトの名無しさん [2019/06/17(月) 01:08:20.00 ID:kwIqiH/S.net]
- こんなオワコン老害スレにガキなどおらん。
いるのは無職とヨコからマウンティングするだけの糞じじぃのみ。
- 244 名前：デフォルトの名無しさん mailto:sage [2019/06/17(月) 06:40:10.09 ID:dkYFNC1r.net]
- >>232
おまえはどっち？
- 245 名前：デフォルトの名無しさん [2019/06/17(月) 12:15:35.07 ID:IT0P3J54.net]
- WPFの使い勝手はともかく、使い手数に対して仕事はそれなりにあるんだからオワコンではないっしょ
- 246 名前：デフォルトの名無しさん mailto:sage [2019/06/17(月) 19:39:32.64 ID:fDhMMT3f.net]
- COBOL的論理
- 247 名前：デフォルトの名無しさん [2019/06/17(月) 21:35:53.79 ID:Z9iR9gFd.net]
- 60年現役のCOBOLさんを いつ消えるか分からんWPFなんぞと一緒にしないでくれたまえ笑
- 248 名前：デフォルトの名無しさん [2019/06/18(火) 06:15:24.31 ID:3nOE2mBA.net]
- プログラム板にキチガイ降臨中！botに一晩も反応する異常さ
一般人(学校恩師)に殺害予告をしているのでスレ建て通報してください。
https://mevius.5ch.net/test/read.cgi/tech/1559872586/
142 名前：a4 ◆700L1Efzuv 投稿日：2019/06/18(火) 05:29:55 ID://qVkzO
>>141
名古屋の人な 俺ね、君の問題を大橋先生と混ぜないことにする。つまりね、
片桐孝洋のことをボコろうと思う。普通に顎の骨を折る。これくらいで警察来るか？
一般市民とかさ、普通にさ、俺らの秘密なんだけどさ、日本人な
- 249 名前：んて復活ねーから。 []
- [ここ壊れてます]
- 250 名前：デフォルトの名無しさん [2019/06/18(火) 20:27:06.42 ID:ei8mZ0vT.net]
- 設計が糞すぎたから普及に失敗した。これがすべて。
- 251 名前：デフォルトの名無しさん mailto:sage [2019/06/18(火) 20:44:01.17 ID:PMWmWCmS.net]
- COBOLをボコる
- 252 名前：デフォルトの名無しさん [2019/06/18(火) 22:46:24.39 ID:1c5MtUw2.net]
- XAMLのデザイン要素は悪くないと思うけど
MVVMとかに関しては労力に見合ったリターンがあるか疑問
個人的にはバインドとかいろんな書き方できるのがすごくイヤ。
バインドでもx:Name=でも良いんだが、Pjによって原則どっちかでしか書けなくしてほしい。
- 253 名前：デフォルトの名無しさん mailto:sage [2019/06/19(水) 18:45:04.98 ID:eIRWm2fN.net]
- >>240
それは規約の話じゃないか？
- 254 名前：デフォルトの名無しさん [2019/06/19(水) 20:02:02.54 ID:Td37eomm.net]
- 両方じゃない？
昔の言語でgotoでスパゲッティの成果物があったとして、書いたヤツや規約も悪いしgotoオッケーの言語も悪い。
- 255 名前：デフォルトの名無しさん mailto:sage [2019/06/20(木) 19:00:34.81 ID:OKnd5gHF.net]
- WPFで業務用アプリを作ってみたけどなかなかいいじゃない。
Material Design XAML Tool Kitのおかげでサクッと今風のUIが実現できて褒められたわ。
データバインディングしなかったからだと思うけどわりかし簡単に作れるし便利。
- 256 名前：デフォルトの名無しさん [2019/06/20(木) 22:52:20.47 ID:HND361/m.net]
- バインドは自分で全部やるにはまだ良いのだけど、他人のバグを解析する時のめんどくささが半端ない。
- 257 名前：デフォルトの名無しさん mailto:sage [2019/06/21(金) 21:27:48.13 ID:n+3asy/J.net]
- そこでx:Bindですよ
- 258 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 00:12:48.90 ID:fySNt3rb.net]
- COBOLにボコられるレベルか。否定はできない。
- 259 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 00:40:47.93 ID:2eisPF//.net]
- exe作れるなら別にUWPでもいいんだけどな
- 260 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 01:00:34.07 ID:65ybortV.net]
- イベントがバブルがどうとかちゃんと理解できてないまま廃れ始めてしまった
- 261 名前：デフォルトの名無しさん [2019/06/22(土) 11:40:15.33 ID:rEuWV0gj.net]
- 言語がはやるかに、入りやすさは大事だからな。
バインドでキレーに実装したのに、メンテした奴が手続き型でやってるとスゲーがっかり。
人材確保がむずいなら、最初から手続き型でやった方がいーわ
- 262 名前：デフォルトの名無しさん [2019/06/22(土) 11:53:14.62 ID:rEuWV0gj.net]
- バインドのメリットとして分業しやすさが挙げられるけど、xaml と vmを別の作業者がやることなんてあんまり無いと思う。ほとんどのケースではコード量が増えてメンドイだけw
- 263 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 12:11:23.53 ID:8ehMgppn.net]
- MVVMはクラスの数が増えるけど画面更新が楽なのがいい
ReactivePropertyと組み合わせるのが好き
- 264 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 12:40:42.40 ID:5GxlA/I5.net]
- >>250
テストのしやすさやろ
- 265 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 12:52:59.27 ID:Y4Y2JNgB.net]
- MVCのほうがテスト簡単でいいや
- 266 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 12:54:31.72 ID:gdHFdK5j.net]
- テストせんやつにテストの楽さを説いても仕方ないやろ
- 267 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 12:58:17.43 ID:Y4Y2JNgB.net]
- VMのテストをしてもE2Eテストをしなくていいわけじゃない
振る舞いが複雑化する傾向が強いMVVMはテストにおいてもデメリットが大きい
単純なMVCならE2Eテストも楽ちん
- 268 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 13:00:36.93 ID:5GxlA/I5.net]
- >振る舞いが複雑化する傾向が強い
ソースよろ
- 269 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 13:03:08.40 ID:Y4Y2JNgB.net]
- >>256
手元のWPFアプリソースでもみればいんじゃね？
- 270 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 13:10:11.63 ID:gdHFdK5j.net]
- ジャ…どこかのSIerらはE2Eテストを人力でやるのが最良だとみなしてる節があるがな
- 271 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 13:16:43.11 ID:Y4mhjvqt.net]
- >>258
それは正しいよ
一度きりのテストなら自動化はコストに見合わない
SIerなら納品後はどうせあまり弄らないし、仮にメンテが必要になったとしてもは都度工数を請求できるから無問題
- 272 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 13:23:15.77 ID:opiN2/uR.net]
- なんと言っても数字でレイアウト出来るのが良い
マウスでポトペタは楽だけど美しくするには可也面倒だからね
- 273 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 13:24:06.96 ID:1mmW7z7g.net]
- 単純なMVCアプリしか作ったことない人：「MVVMは複雑だからテストが大変」
こういうこと？
- 274 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 13:28:47.48 ID:5GxlA/I5.net]
- >>261
たぶんそういうこと
ただの妄想やで
- 275 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 14:23:52.15 ID:Y4mhjvqt.net]
- >>262
事実やで
というか論理が逆で、そもそも複雑だからMVVMを使うんだよ
だから典型的なWebMVCに比べてテストが大変なのは当たり前
- 276 名前：デフォルトの名無しさん [2019/06/22(土) 14:42:56.00 ID:rEuWV0gj.net]
- MVVMのテストは楽だと思う。
コーディング・テスト・バグ修正の合計時間で考えると得してるかは疑問だけど。
- 277 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 15:50:17.05 ID:5GxlA/I5.net]
- >>263
事実ならソースよろ
- 278 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 15:56:59.09 ID:1mmW7z7g.net]
- >というか論理が逆で、そもそも複雑だからMVVMを使うんだよ
なら原因はMVVMであることではなくてその前に複雑であることになるが、
自分が何を言っているか理解しているんだろうか。
- 279 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 15:59:36.88 ID:x9ZPs6AR.net]
- >>256
>>265
バカじゃねぇの
- 280 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 16:00:33.66 ID:Y4mhjvqt.net]
- >>266
だからそう言ってる
UIの要件が複雑だからWPFを採用し、WPFが複雑だからMVVMを採用する
- 281 名前：デフォルトの名無しさん mailto:sage [2019/06/22(土) 16:07:07.54 ID:5GxlA/I5.net]
- >>267
妄想なら誰にでもできるもんね
- 282 名前：デフォルトの名無しさん [2019/06/22(土) 16:37:06.55 ID:rEuWV0gj.net]
- 少なくともUIに関しては複雑だからより、見た目的な理由でWPFだと個人的には思ってるｗ
|
 |
