ふらっと C#,C♯,C＃（初心者用） Part137
■ このスレッドは過去ログ倉庫に格納されています
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください
>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。
■関連スレ
C#, C♯, C＃相談室 Part95
http://mevius.5ch.net/test/read.cgi/tech/1508180530/
C#, C♯, C＃相談室 Part93
https://mevius.5ch.net/test/read.cgi/tech/1492818720/
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part136
http://mevius.5ch.net/test/read.cgi/tech/1520057345/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/
■情報源
https://msdn.microsoft.com/ja-jp/library/gg145045.aspx
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://msdn.microsoft.com/en-us/library/gg145045.aspx
http://referencesource.microsoft.com/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured >>519
Gitでsqliteの差分見るのかい？ >>513
XLS: バイナリ, 標準化されてない(されてるかも知らんが概ねExcelないと読めん)
CSV: not well standarized
XLSX: zip圧縮されたXMLじゃん >>520
dbの比較は簡単
バージョン管理の機能にはないけど >>504
VSCodeのセッティングはネストが浅くて比較的読みやすいし、VSCodeによるコード生成がうまく機能してるからね >>521
ビジネスでExcel入ってない環境とかあるの？ エクセルからマスターや設定をインポートするようになってるシステムは壊しそうで怖いわ
うっかりレイアウトがズレてて正しくデータが取れなくなるとかよくある
バージョン管理の問題にも関連するけど、再現性が乏しいんだよエクセルは >>522
おれsqliteのバイナリをテキストエディタで書き換える能力ないのよ >>524
DB同士のデータの比較したことねーの？ >>517
そこの会社の内部の抗争があるんだと思う
いまどきxhtmlを使ってる派閥がいて
そいつらが不利になったので意味不明なテストでxhtmlすげーをやって
何も考えないやつがそれに賛同したと
エジソンが高圧送電は危険だと言って動物を殺す実験をしたようなもの >>525
開発は仮想のLinux上とか普通にあるから >>528
json vs xmlの比較とは全く異なる次元のものを持ち込んで比較しようとするクズ >>533
こいつdotnet newすら打ったことなさそうだな >>532
そっちは完全に編集するツールがないじゃん
あってもゴミみたいなのしか >>533
開発用システムでXLS読むために入れるとか本末転倒 >>536
お客さんに何で編集したいですか？
って聞いてみろよ
Excelでできるって言ったら大喜びするぜ >>535
専用ツールがないと編集できないものなんてイラネ >>506
Excelの場合はそもそもツリーデータ構造を表現するためのスタンダードなフォーマットが無いので比較する以前の段階
まずはツリー形式のデータ構造を表現するためのフォーマットのデファクトスタンダードを業界全体で決めてくれ
比較はその後に回していいんじゃないかな vscodeのsettings.jsonとか見せたら発狂しそう >>537
客は会社のシステム部門なんで別にExcel喜ばれないですむしろ殴られそうです あとXLSXはともかくXLSをC#から弄ったことないんだけどExcelなしで読めるの？
COM使って読むとか言わないよね？ >>517
やっとちゃんと読んでレスしてる人が来た
確かにもともとXMLをベースに考案されたデータ構造なのでXMLに有利と言えるかもしれない
しかしそれを認めると議論の発端である「jsonはxmlより優れている」という命題を「対象次第ではxmlのほうが有利である」という命題で最初から否定することになってしまう
本当に「jsonはxmlより優れている」なら対象がXHTMLだろうとなんであろうともjsonのスコアが高くなっていなければおかしい なんでもかんでもExcelでやりたいVBAer()さんはVBAスレにおかえりください
事務員さんの常識はプログラマには通用しません >>543
ExcelCreator使って、Excelのインストールされてない環境で読み書きしてた
昔々ね >>465
横から失礼。マイクロソフトの人もそう言ってるよ >>543
OLEDB使えばExcelインストール無しでも読めるで この手の議論はUI入力とデータ保持を同一のものとして考えちゃうから平行線だわな >>544
キミが変なこと言ってるだけ
業務での作業性、操作性においてスマホよりPCがすぐれてるという人に対して
PCではタッチ入力できないとかそんな難癖つけてるだけ >>478
EndsWithに第二引数とかあったのか
いけるわ！ありがとう >>550
それ以前の話でしょw
設定データをユーザーが編集したいなんてかなり特殊な前提でありかつ質問者も
そんな要件を一言も上げてないのにアホかと、
.NET標準のシリアライザではなくあえて外様を使う理由はと聞いて、返って来た明確な答えは
結局「そっちの方が目新しいから」だけ。
中学生じみてるよと言ってるそばからこれだ。
プログラマ板みたいな話になっちゃうけど、本当今じゃプログラマって知能指数が低い奴が
やる仕事になってることを実感するよ json,.netを使うのは早くて使いやすいからだと思う
使いやすいと書くとまた難癖つけられそうだけどｗ >>556
どういう観点で見たときの使いやすいなのか説明が無いよね？ 自分が json を使うとしたら、
・周りが使ってるから
・xml と比較して見た目が好み
って程度の理由だなあ。
どっちが優れてるかの比較なんてそれ自体がズレてるような。 結局Windowsのフォームアプリの設定ファイルは何が適してるんだよ
jsonでもxmlでも大差ないよ好きな方どうぞって結論でいいの？ >>562
そもそも今時フォームアプリなんか採用する時点で全力で時代に背を向けてるんだからどうでもいいよ >>562
configファイルにjson形式で書き込む >>564-565
質問者は「ポータブルアプリの設定ファイル」と言ってる。
ポータブルアプリがUSBメモリに入れて持ち歩くような物のことを言ってるなら、
Settingsは明らかに不適切
あと、個人的にあんまりアプリケーション設定使ったことないんで勘違いしてるかもしれんが、
これって結構制限も多いしいろいろ面倒だよね 質問者ですが、こんなに荒れてしまうとは、、、申し訳ない。
おっしゃるように通常のWindowsフォームアプリならSettingsがデザイナで設定できるし楽なんですが、
ファイルの格納先がローカル(Roamingだったかな？)になるのでUSBメモリなどに持ち運んで使うポータブルアプリとしては採用できないというところでの質問でした。
特に設定ファイルの可読性を求めないようであれば、
形式としては古いが追加ライブラリ不要のXMLか、
スタンダードな形式だが別途追加ライブラリ必要なJSONか、
好きな方を選べって感じですかね。。 ユーザー定義リソースにしてexeに直接書き込むって方法もあるよ >>568
USBで運ぶポータブルアプリ程度ならApplicationSettings保存でもいいんじゃないの？ アプリケーションスコープにするとアプリから書き込みできないよ >>571
でもアクセスの速度違うときあるからね。 すいません。
初心者なのでこちらに移動してきました。
MVC的な設計で
初期設定値を入力するフォーム
↓
初期設定値を格納するクラス
というのを作りたいのですが、
A.
クラス側に各変数のプロパティを作成
フォームからプロパティを介してクラスの変数に値を代入
B.
クラス側にフォームの初期値を取りに行くメソッドを作成
クラスからメソッドを実行してフォームに値を取りに行く
のどちらが良いのでしょう？
自分ではAの方がよさそうな気がするのですが、一般的な設計としてこうするというのがあったら教えてください。 ケツの穴から手をつっこんで奥歯をがたがたみたいなBよりA >>574
どっちでも動きゃいいだろ
さっさと完成させろよ >>574
// form
void btnSaveInitialSettings_Click(object sender, EventArgs e) {
try { this.SaveInitialSettings(); }
catch(...) { ... }
}
void SaveInitialSettings() {
var initialSettings = this.GetInitialSettings();
var reaction =
this.initialSettingsController.SaveInitialSettings(initialSettings);
reaction?.Invoke(this);
}
// controller
Action<IInitialSettingsView> SaveInitialSettings(InitialSettings initialSettings) {
this.initialSettingsService.SaveInitialSettings(initialSettings);
return view => view.Refresh();
} 初心者は出来上がってから検討すりゃいいんだよ。
つうか、プロ目指してるなら、先ずは完成させる癖を付けないとな。
万年アマチュアでいいのなら些末な問題で盛り上がればいいさ。 まず終わらせろ、Facebookのにいちゃんも言ってたべな。 Facebookにいちゃんが誰かわからんがそいつが言うまず終わらせろ、とお前が考えるまず終わらせろは別物だと思うぞ
ユニットテストとリファクタリング込みでまず終わらせろ、って言ってるならマトモだけど、将来のことなにも考えずまず終わらせろって言うならただの害悪 >>580
リファクタリングなんか完成した後にバージョンアップする機会があったらやればいいんだよ。 将来が有るかどうかなんて、売れてから考えろw
タイムイズマネーだ。無駄なリソース費やしてる暇が会ったら次の案件片付けろ。 >>581
そうだよね
エッチな絵が一枚も表示されないのにリピーターがいることを想定してる
なんてピンボケもいいとこだよね
割とマジで 仕様通りの動きだけど汚いコードと
仕様通りの動きじゃないけど綺麗なコード
を同じ時間で仕上げたとして、どっちが優れているかと言えば前者だよな >>584
そりゃ仕様満たしていないなら比較以前の問題だわな
仕様満たして完成までの期間で比較とかならともかく まあ、熟練者になれば、素早く仕様通りのコードを綺麗に仕上げて来るからな。
初心者は先ず動くコード、次に仕様通り、最後に綺麗なコードでいいよ。
時間掛かるのはこの際問題にしないw リピーターが多い汚いコードと
リピーターが少ない綺麗なコード
後者はゴミだよね 世の中の多くのバカが勘違いしてるんだけど
綺麗なコード==間違えやすい製造に時間がかかるコード
じゃないんだよね
綺麗なコードはバグが少ないし製造も早い
汚くても動くコードを早く書け！なんて言ってるやつは根本的に何かがズレてる
そんな方針でコーディングしたら汚くて動かないコードを時間をかけて作る羽目になる 洗練された華麗なコードとインデント揃っただけの綺麗なコードを混同してるばか発見 >>574
UI(Form）がモデル（何か仕事をするクラス）の参照を持つのは問題ないが、
逆は良くない。理由は、
(1) 役割分担があいまいになる
厨房の人間が1分おきにウェイターに注文を確認するのは適切な役割分担と言えるか？
(2) つぶしがきかない
Formの参照を握ってFormのメンバーを操作するクラスは、UIをWPFやUWPに
変更しても使いまわしできるか？ >>577
一読で理解できる知識がないのですが、勉強してみます。
ありがとうございます。 >>590
UIがデータ格納用クラスのインスタンスを生成
UIがプロパティを介してデータ格納用クラスの変数に代入
UIがコントローラにデータ格納用クラスのインスタンスを渡す
みたいな感じでよろしいでしょうか？ >>592
＞UIがデータ格納用クラスのインスタンスを生成
誰がモデルのインスタンスを生成するかはケースバイケースだしどうでもよろしい
＞UIがプロパティを介してデータ格納用クラスの変数に代入
重箱の隅をつつくようだが、オブジェクトのプロパティやメソッドを操作する時に
「データ格納用クラスの変数に代入 」なんていう内部の実装を意識する必要はない。
必要はない、というか意識しなくても使えるように作るのがカプセル化。
＞UIがコントローラにデータ格納用クラスのインスタンスを渡す
俺がMVCを理解してないだけの可能性もあるが、少なくともWindows Formでは
VとCを分けたりしないのが普通と思う。コントローラなんてｲﾗﾈ 話蒸し返して悪いんだが、xmlシリアライザーって今使ってるとやばいの？業務アプリの設定ファイルほぼこれで今までやってたんだが。。
とりあえず今やってる案件JSONで見直してみるか
一人で開発やってるとついついこういうのに遅れがちになるなぁ csvとJSONなら圧倒的に後者のがメリットあるけど、
xmlとJSONなら規模がでかくない限りどっちでも良いや >>594
業務ドカタ系でJSONなんかほとんど無いから安心しろ
客サイドは情シスですらJSON何それとか平気で言いやがるしOSSのライブラリが必要なのもネック >>596
Excelで編集できるできないって違いもあるのに
どこが「圧倒的」なの？
根拠もない主張を強く推すなよ
願望だろ？お前の PCのiTunesって曲の情報管理全部XMLだよな
どうにかならんのか
https://i.imgur.com/zaooQAM.jpg Ant, Maven とか、Java系は、XML。
Android 画面の設定ファイルとか
Windows でも、XAML で画面設定する
プロジェクトの設定ファイルも
JSON を設定ファイルに使うのは、JavaScript を使ったもの。
例えば、Node.js を含んだ、VS Code
他には、プログラミング言語自体が設定ファイルになるもの。
Ruby, Groovy, Haxe >>594
え？全然やばくないよ
むしろ安定した手堅い選択肢と言っていい
JSONを設定に使う製品はむしろ少数派 >>600
>JSON を設定ファイルに使うのは、JavaScript を使ったもの
最近のC#もそうですが >>594
ヤバイってどういう状況？
殺されるの？ >>602
project構成は不評で結局xmlに戻ったね
ASP.NETのappsettingsはボイラープレートがjsonになってるけどxmlやiniもサポートされてる 素のJSONはコメントが使えないので設定ファイルには使い辛い。 川俣さんのことを馬鹿にする人が2chには多いけど、この記事の趣旨は正しいと思う
http://www.atmarkit.co.jp/fdotnet/extremecs/extremecs_18/extremecs_18_02.html
特定の技術への信仰と「俺スゲー」っていう間抜けな自己陶酔が結びついてる奴ってよくいるし、
このスレにも時々そんなのが出るけど、そういう奴のいうことは真に受けない方がいいですw つか業務で使うなら余程のことがない限り枯れた技術の方が安定する COBOLは実際優れてるんだよなあ
低品質なPGでもほぼ完璧に見積工数通りに仕上がるし、バグもほとんど出ない
金持ちな客からきっちり工数見合いで金取れるならSIerにとってこれほど好都合な言語はない 工数が低減できるかどうかよりも見積が精確にできることの方が管理者にとっては重要ってわけだね 大体この時間にABENDしますって
異常停止をルーチンワーク化して運用している所があったな 現場運用だと稀によくある
開発側がそれを織り込んじゃダメだけど >>594だけど
蒸し返した話にレスくれてありがとう
自分の用途にはxmlでも問題なさそうでとりあえず安心した ■ このスレッドは過去ログ倉庫に格納されています
