VB.NET質問スレ(Part43) [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2016/06/15(水) 11:41:09.50

前スレ

VB.NET質問スレ(Part40)
http://toro.2ch.net/test/read.cgi/tech/1365857015/
VB.NET質問スレ(Part41)
http://peace.2ch.net/test/read.cgi/tech/1391334405/
VB.NET質問スレ(Part42)
http://echo.2ch.net/test/read.cgi/tech/1419148239/

**デフォルトの名無しさん** · 2016/07/15(金) 20:21:13.97

お前らVB.Netなんかやってるの？

俺なんか今の仕事場VB6.0だぞ。
CPUはPen4でOSなんかまだXP。
XPはマズいので何か機会が有ったら通報してみようかと思ってる。

**デフォルトの名無しさん** · 2016/07/15(金) 20:59:19.37

>>54
ありがとうございます！

**デフォルトの名無しさん** · 2016/07/15(金) 22:41:00.37

>>55
確か明治時代はみんなそうやってたんだっけ？

**デフォルトの名無しさん** · 2016/07/15(金) 22:53:00.93

>>58
教えてください
明治時代のVSのバージョンはいくつだったんですか？
Windowsのバージョンは？
CPUは何だったんですか？
ビル・ゲイツは生まれてなかったと思うんですがマイクロソフトはあったんですね？

**デフォルトの名無しさん** · 2016/07/15(金) 23:33:10.42

>>59
煽るならもうちょっと捻れよ
VBerの知能レベルが知れる

**デフォルトの名無しさん** · 2016/07/16(土) 00:34:50.26

>>58
VB6.0の時代、ベテランプログラマーがそう書いてたから真似した。
今もそのクセが抜けない。

**デフォルトの名無しさん** · 2016/07/16(土) 09:09:16.76

>>60
じゃあ知能レベルの高い()煽りを御享受ネカ゜得るかな？
知能レベルが高いなら出来るよねw

**デフォルトの名無しさん** · 2016/07/16(土) 12:22:45.14

なんなら俺が最高峰の煽りを見せてやろうか？

**デフォルトの名無しさん** · 2016/07/16(土) 13:21:59.74

でもこれで>>60がやってるのがjava辺りだったらウケるよな

**デフォルトの名無しさん** · 2016/07/16(土) 16:47:05.11

フォームにボタン１つ設置して、そのボタンおすと新しいエクセルのファイルが作られるようにしたいのだけど、どうやればよいですか？
参照の追加から、ライブラリ？を追加することをしなければならないのはネットで理解したのですが、
さしあたりサンプルコードなどをコピペしてみても、エラーに泣てうまくいきません

**デフォルトの名無しさん** · 2016/07/16(土) 17:12:58.61

ファイル作るだけなら空のファイル用意しといて名前つけてコピーするだけじゃんw

**デフォルトの名無しさん** · 2016/07/16(土) 19:37:10.54

>>51
checkboxとlistboxがペアになってるならUseControl作るのが正解だろうね

**デフォルトの名無しさん** · 2016/07/26(火) 12:49:23.36

ASP.NETなんですが、

フォーム認証をやってますが、ログインフォームで、
System.Web.Security.FormsAuthentication.SetAuthCookie(userID, True)
という風に、永続化させたとします。

んで、次回からはクッキーが削除されない限り、ログインフォームに来ないで
前回のログイン情報が生きてるように見えます。(Context.Userに値が入ってきてる)

ここまでは全く問題ありませんが
ログインフォームでは、userIDに応じたユーザー名(漢字)もDBから取得していて
Session("userName") へ格納しています。

永続化させると次回からはログインフォームに飛んでこないようになるため
この仕組みが通らず、Context.User に値は入ってるけど、Session("userName")は空という事態が起きます。

永続化させた後にも、ログインと同等の処理がglobal.asaxの中のどっかを通ると思うんですが
Context.Userの値でDB検索して漢字名をSession("userName")にセットするにあたり
global.asaxのどこへ書くといいですか？

**デフォルトの名無しさん** · 2016/07/26(火) 21:07:32.60

Sessionが認証状態を超えるなら考えないといかんが
とりあえずSession_Startあたりで良いんじゃね

**デフォルトの名無しさん** · 2016/08/15(月) 21:51:30.36

・商品がカテゴリ分けされていて階層で管理されている (例. カテゴリ1　→ カテゴリ1-1 → カテゴリ1-1-1 → 商品A)
・商品管理画面にカテゴリの階層構造をツリーとして表示する(顧客からの要望)
・管理する商品件数は1000件程度
・ツリー内の好きな位置で新しい商品を追加したり、商品を削除したり、カテゴリ(ツリー構造)を変更したりする
・ツリー内容は全展開する(顧客からの要望)

上記のような機能を実装しているのですが、
1000件程度でもツリーにノード追加したり、階層構造を変更したりすると時間が掛かってしまいます。

BeginUpdateで描画更新をとめる処理を入れるのは既に試していますが、
レスポンスが悪いと感じております。

そこでTreeViewでBeginUpdate以外の方法で処理を早くする方法もしくは、
階層構造が表現できて1000件程度でも高速であるTreeView以外の代替コントロールはありますでしょうか？

**デフォルトの名無しさん** · 2016/08/15(月) 22:50:45.95

1000件とかなら適当なグリッド使ったほうがいい

70 · 2016/08/17(水) 05:55:50.00

>>71
レスありがとうございます。
グリッド関連ででツリー構造をうまく表現できるものがあるか調査してみたいと思います。

**デフォルトの名無しさん** · 2016/08/19(金) 13:22:10.36

パネルを敷いて、その上にボタンを貼り付けるとします。
ボタンの位置、上左を起点にして位置決めしたとします。

んで、ボタンの上と下の余白とが同じになるように
パネルの大きさを弄ってますが、これが極めて面倒
(プロパティウィンドウでサイズを数値で打ったほうが早いレベル)

デザイナでマウス使って、簡単に位置合わせできないもんでしょうか。

**デフォルトの名無しさん** · 2016/08/19(金) 13:29:16.02

>>73
同じ物（パネルの中にボタンがある）が複数あるのならコピペすりゃいいんじゃないの？

そもそも本当にパネルの中にボタンが一つだけ（と言ってるように聞こえるけど）しかないなら
パネルが必要あるように思えないんだけど。

**デフォルトの名無しさん** · 2016/08/19(金) 21:27:55.12

>>73
a) プロパティウインドウでサイズを打つ
b) デザイン時は適当に配置して実行時にサイズ変更する
c) VisualStudio のアドインを作る

**デフォルトの名無しさん** · 2016/09/01(木) 22:14:52.74

これから自作の業務ソフトを作る為に勉強始めようと思うのですが、まともなコーディング出来るまでどれくらい時間かかるもんでしょうか
VBAをちょこちょこやってるレベルです
会社に出来る人はいないので独学しかないです
いい勉強方法などあれば教えていただきたいです

**デフォルトの名無しさん** · 2016/09/01(木) 22:42:58.64

>>76
c♯にしとけ

**デフォルトの名無しさん** · 2016/09/01(木) 22:53:09.46

>>76
目的のものがあれば調べまくってとりあえず、動くものを作る。
ちゃんと動けば楽しくなって、更に深く調べる。
こんな繰り返しでだんだんと上達してくるんじゃない？

最初からキレイで無駄のないコードを書くのは難しいよね。
どのくらいの期間かは、本人の努力でいかようにも短くなるんじゃない？

**デフォルトの名無しさん** · 2016/09/02(金) 20:43:57.57

>>77>>78
ありがとうございます。
.NETで一通りコーディング出来たらC#で同じもの作ってみたいと思ってます
とりあえずやってみるしかないですよね。作りたいものは決まってるので頑張ってみます
クラス設計出来るようになるだろうか。。

**デフォルトの名無しさん** · 2016/09/02(金) 22:14:27.15

VBは情報の質が低いから初心者は変な癖が付きやすい
まともにオブジェクト指向を解説してる書籍なども少ない
どうせC#もやるつもりなんだったら最初からC#でいくほうが近道だよ

**デフォルトの名無しさん** · 2016/09/02(金) 22:16:49.34

c#厨が必死だなw

**デフォルトの名無しさん** · 2016/09/03(土) 00:43:38.63

まぁC#でもjavaとかに比べるとObject指向の本とか少ないけどな。VBよりマシってくらいで。
C#もjavaも似たような構文してるから両方やっとくといい。
ついでにC#とVBも構文じゃなくて中身がそんなに変わるもんじゃないから一緒にやっとくといいよ。

**デフォルトの名無しさん** · 2016/09/03(土) 08:27:57.79

VBはオープンソースプロジェクトがほぼ皆無だからなあ
「スキルの高い人が正しく使えばこうなる」というものに触れる機会が無いのは致命的

**デフォルトの名無しさん** · 2016/09/03(土) 12:35:14.12

vbは構文が破綻しかけてるからこれからプログラミングを始める人がやるべき言語ではない

**デフォルトの名無しさん** · 2016/09/03(土) 12:40:16.59

.NETがとっつきやすそうだったのでクラスがどういったものがあるか勉強しながらC#に移行出来ればと考えてたんですが
.NETだとオブジェクト指向らしくないコーディングをする癖がついてしまうでしょうか
C#に移行すればそんなこともいってられないくらい矯正できますかね？

**デフォルトの名無しさん** · 2016/09/03(土) 12:42:48.70

>>84
マジすか。。素直にC#から入ろうかな

**デフォルトの名無しさん** · 2016/09/03(土) 12:59:42.87

いや、VBの方がC#より簡単とか今はないよw
宗教論争抜きでもうあえてVBを選択する理由はないから、素直にC#にした方がいいと思う。

**デフォルトの名無しさん** · 2016/09/03(土) 13:37:14.87

ただVBはやっておくと結構いきなりVBAのコードが書けたりする

**デフォルトの名無しさん** · 2016/09/03(土) 13:38:51.14

FrameworkがC♯なんだから素直にC♯にしとけよ

**デフォルトの名無しさん** · 2016/09/03(土) 13:47:15.45

VBは大文字小文字の区別がないからパンチが雑になる
VBやったあとにC#触るとあれっ？てなる

かっこで条件をかかなくていいのはVBの唯一好きな点だな

**デフォルトの名無しさん** · 2016/09/03(土) 13:47:46.48

あ、If文の話ね

**デフォルトの名無しさん** · 2016/09/03(土) 14:50:51.90

>>87
c#を選ぶ理由も無いのにc#をゴリ押しするのは宗教戦争でなくて何？
c系は見た目が嫌だから嫌いって俺みたいなのもいるんだが？

**デフォルトの名無しさん** · 2016/09/03(土) 15:11:32.11

>>92
気付いてないみたいだけど、まさにお前さんがやってるようなことが宗教論争なんだよw

見た目なんて慣れの問題だよ。多くの人がそう言ってるでしょ。
本当に致命的に欠点があるのならこんなにC#が支持されてるわけないじゃん。

そういう個人の好みは置いといて、今から始める人がどちらを選んだ方が得をするか、
そういう話でしょ。

ユーザー数や公表されるサンプルコードの数でC#が勝るのは客観的事実だし、.NETの標準がC#なのも事実。
要するにC#を選んだ方が圧倒的に得なのは動かしがたい事実だよ。

**デフォルトの名無しさん** · 2016/09/03(土) 15:29:02.10

そらまあ構わないが
ならC#スレでやってくれ

**デフォルトの名無しさん** · 2016/09/03(土) 15:39:32.30

出たw
｢多いから｣
多いのが良けりゃトヨタ車が一番いいクルマだわなw

**デフォルトの名無しさん** · 2016/09/03(土) 16:49:33.83

一番の違いはC#を覚えればVBは自動的に使えるようになるけど逆はそうでもないという点だな
そして初学者にとっての学習コストはC#のほうが低いんだからVBを選ぶ理由がない
C#使える人でVBにコンプレックス持ってる人はまずいない
その逆は見ての通りだ

**デフォルトの名無しさん** · 2016/09/03(土) 16:53:33.28

>>96
＞C#を覚えればVBは自動的に使えるようになる
さすがにそれはないよw
っていうかその程度にはVBerもC#使えるでしょw

**デフォルトの名無しさん** · 2016/09/03(土) 19:28:47.71

まあ、ホントに全く新規で始めるのにVBかC#かってなら俺もC#を勧めるが
>初学者にとっての学習コストはC#のほうが低い
には同意できん

よい教材か、正しい指導者が居るなら同程度かVBが勝る
ただし、それに当たる確率はC#の方が多いけどな

**デフォルトの名無しさん** · 2016/09/03(土) 19:35:40.75

>>98
いやC#の方が覚えること少なくて初心者向きだと思うよw

VBはなまじ今となっては使わない方がいいレガシー機能とかあってとっつきづらいと思う。
WitheventsとHandlesでとりあえずデリゲートを理解しなくてもイベントが使えるとか、例外もあるけどねそりゃ。

**デフォルトの名無しさん** · 2016/09/03(土) 21:04:33.37

覚えるのが少ないって
キーワード増やしたくないって結果が
+=でイベントハンドラ割り当てたり、拡張メソッドにthis指定しろとか言う言語だからなぁ

ちがう機能には違うキーワード割り当てる方が初心者むきだぞ
今となっては使わない方がいいレガシー機能とか初学者に教える必要ないし

**デフォルトの名無しさん** · 2016/09/03(土) 21:31:23.31

>>76みたいにVBA経験者ならVB.NETの方が敷居は低いだろうね

**デフォルトの名無しさん** · 2016/09/03(土) 21:37:06.88

そうかな
雰囲気が似てるだけの全くの別物だから、ちゃんと「プログラミング」として入門し直すにはVBAの知識なんか邪魔になるだけだと思うが

**デフォルトの名無しさん** · 2016/09/04(日) 02:55:14.23

なんで初心者でない体の物言いばかりなの？
まるで説得力が感じられない
自分の身の丈に合った目線で話せば良いのに

**デフォルトの名無しさん** · 2016/09/04(日) 03:25:42.67

<sammary>タグ中に<para>いれてもxmlドキュメントで改行できないんだけど、仕様？
VS2012ね

**デフォルトの名無しさん** · 2016/09/04(日) 03:32:24.20

自分の場合AccessVBAですが、その知識が邪魔になった事はありませんね
VB6というかVisualStudio6.0の知識(仕様)が邪魔になった事はあります
基本的にVBAやVB6で培った知識は役に立ってますよ
また、似てる似てないはVBAからVB.NETへの移植をやると似てるのが良く分かります
稀なケースですが関数の中身をそのまま新メソッドに張り付けるだけで動く事もあります

**デフォルトの名無しさん** · 2016/09/04(日) 07:58:22.83

まぁVBとVBAは全くの別物ってことはないな。
ただ、まずVBAだけやっていた場合はクラスを使って
ポリモーフィズムで、
とかそんなところにすら至れない人が多い。

.NetやっててVBAの改修作業とかたまにやると
まるでコードのステップ数の多さをドヤ顏で自慢するかのような関数とか平気で作られていて
ストレスが溜まることもよくある。

ただ、今の仕事場でjavaで作られているシステムは1メソッド5000行とか有ったりするので
改修するとき作った奴に殺意を覚えたりするけどね。

**デフォルトの名無しさん** · 2016/09/04(日) 08:33:24.52

>>104
xml自体から消えることはないはずだからそれをどう表現するかは使う側次第
とりあえずインテリセンスに影響しないのは仕様

**デフォルトの名無しさん** · 2016/09/04(日) 12:24:52.05

>>107
インテリセンスにこそ影響しないと論外なのにな…
というかC#だと改行されるみたいだね
仕方ないからユーティリティ系（そもそもこんなものを作りたくないが）はC#で組むことにするよ

**デフォルトの名無しさん** · 2016/09/04(日) 17:33:53.38

VB.NETもC#も、東北弁と九州弁の違いでしかないだろ
似たり寄ったり

C++も使える俺だけど、C#ってもVBみたいに感じる
特に変数の扱い(解放)に不安を感じる

**デフォルトの名無しさん** · 2016/09/04(日) 17:35:13.39

VBにのみあるWith～End Withは素直に便利だと思う

**デフォルトの名無しさん** · 2016/09/04(日) 17:44:16.26

>>110
つ My

**デフォルトの名無しさん** · 2016/09/04(日) 18:11:43.89

>>110
むしろあってもいいけどなくてもいい機能だねw
オブジェクト初期化子が使えるケースが大半だろうし。

WithevemtsとHandlesの仕組みはC#にもあったら便利だと思う。
C#の==の既定の実装は変だと思う。これはVBの仕様の方が優れてるね。

あと、細かいことだけど、C#はフィールドを宣言と同時に初期化する時、インスタンスメンバーを
使えないとか、構造体のプロパティをコンストラクタで初期化できないとか（回避方法はあるが）
もちろん理由はあるんだろうけど奇妙な制約があるけど、VBにはそれがないのはいいね（もちろん弊害もあるんだろうが）

>>111
My爺さんはリソースぐらいしか使わないし、使わない方がいいと思うよw
あえて使う理由がない。
あんなのVBが馬鹿にされる理由の一つになってるだけw

**デフォルトの名無しさん** · 2016/09/04(日) 18:14:32.84

あと、言語としてのVBとは関係ないけど、アプリケーションフレームワークで
結構使える機能あるよね。

これなんかC#から使えたら便利だと思うんだけど
http://www.atmarkit.co.jp/fdotnet/dotnettips/663nextinstarg/nextinstarg.html

**デフォルトの名無しさん** · 2016/09/09(金) 01:12:27.23

VB.net固有ではないかもしれませんが、
VB.netを学習しているのでこちらで質問させていただきます。

Linq to EntityでJoinやGroupJoinなど
リレーションを定義したメソッド用意しようと思っています。
(Linqでリレーションを毎度記述するのはめんどくさいので一か所で済ませたい)

その際、IQueryableで返したいんですけど例えば２つのテーブルを結合したときに、
IQueryable(匿名型)は返せないしIQueryable(Of Tuple(Of Table1,Table2)も無理そうなので
Table1とTable2のプロパティを持ったJoinTableクラスみたいなのを作って
IQueryable(Of JoinTable)にすればできるんですが、
これだけのためクラスを作るのは何となくしっくりこないんです。
この方法しかないでしょうか？

(Code Firstでのテーブルクラスの外部キーでのリレーションや
Fluent APIでのリレーション以外で)

**デフォルトの名無しさん** · 2016/09/09(金) 02:21:34.21

>>114
【VB.NET】LINQ友の会【C#, C♯, C#】
http://echo.2ch.net/test/read.cgi/tech/1202568694/

**デフォルトの名無しさん** · 2016/09/09(金) 20:33:17.26

ふつうリレーションがあるなら、そのエンティティにリレーション定義すると思うんだが
何がしたいのか全く分からん

**114** · 2016/09/11(日) 22:13:12.60

ちょっと質問がイミフでした。
MVCとかMVVMのMでEntityFrameworkを使って
DB関係のロジックをうまいことコーディングしたかったんだけど
もうちょっとアプローチを変えてきちんと整理してから
改めて質問いたします。すいませんでした。

**デフォルトの名無しさん** · 2016/09/22(木) 21:07:27.78

カスタムコントロールにビジネス上の知識を持たせるのって有りですか？
商品コードは特定の正規表現を満たす文字列であるというビジネスルールがあるとします

①正規表現による検証ができるテキストボックスを作り商品コードを扱う各画面に配置してデザイナで商品コードの正規表現を設定する
②商品コード専用のテキストボックスを作る

①はコントロールがビジネスルールを直接知らなくて良いのでUIとビジネス層が疎結合ですが各画面に商品コードの正規表現を設定する手間がかかります
②は製造もメンテナンスも楽ですがUIがビジネスの知識を持つ必要があり結合が強まります

**デフォルトの名無しさん** · 2016/09/22(木) 21:55:50.74

ドンチューシンクソーインディーズレキシカルコンストラントアンドビジネスルール？

**デフォルトの名無しさん** · 2016/09/22(木) 21:57:28.36

検証するコントロールなりクラスなり作って、必要ならそれがテキストボックスの参照持つのが本筋の気はするけど

どこまでUIとロジックの分離をするのかと
ビジネスロジックと定型フォーマットチェック程度の一般的なロジックなのかの切り分けどう考えるかじゃね

個人的にはビジネスロジックを含んだUIパーツがあってもよいと思うけど

**デフォルトの名無しさん** · 2016/09/23(金) 02:12:52.23

>>118
①のカスタムコントロールAを作って
それを継承して正規表現を設定済みのカスタムコントロールBを作る

**デフォルトの名無しさん** · 2016/09/23(金) 02:31:01.60

>>118
どっちもよくないと思うよ。

入力の検証に必要なルール（この場合は正規表現バターン？）はあくまで
ビジネスルール側から提供されるようにすべきだし、それで何の問題もないでしょ。

**デフォルトの名無しさん** · 2016/09/23(金) 02:34:00.44

あ、ちょっと説明が足りなかったけど、要するにこの場合は
カスタムコントトールがビジネスロジック側の適当なクラスにある、検証に必要な正規表現パターンを返す
静的プロパティか何かを参照するだけ。

**デフォルトの名無しさん** · 2016/09/23(金) 12:43:42.35

>>123
>カスタムコントトールがビジネスロジック側の(略)静的プロパティか何かを参照するだけ
ＵＩパーツ（カスタムコントロール）がビジネスロジッククラスに依存するのはどうなのよ

**デフォルトの名無しさん** · 2016/09/23(金) 12:50:22.34

>>124
それは問題ない。
まずいのは逆の依存

**デフォルトの名無しさん** · 2016/09/23(金) 12:53:21.42

そもそも正規表現で制御出来るような単純な字句的制約はビジネスルールとは言わん
それとも数値専用のテキストボックスですらビジネスルールだからUIから分離すべきとでも言う気か

**デフォルトの名無しさん** · 2016/09/23(金) 13:14:59.72

InputManで解決

**デフォルトの名無しさん** · 2016/09/23(金) 13:27:44.13

>>126
正規表現が使えないならビジネスロジック側に検証用の述語メソッドを用意してもらう。

コントロールをより汎用的なものにするために、>>118にあるように
コントロールに検証用の正規表現パターンのプロパティ（あるいはPredicate<T>の
プロパティ）を持たせてもいいけど、その場合もデザイナで正規表現パターンを
設定しちゃうのはまずい。

検証用の正規表現パターン、あるいは述語メソッドはあくまでビジネスロジック側から
受け取るようにしなきゃ

**デフォルトの名無しさん** · 2016/09/23(金) 13:31:47.45

あと、数値だって上限下限があるとか、特定の数値は不可とか、
固有のルールはいろいろありうるよね

**デフォルトの名無しさん** · 2016/09/23(金) 13:35:38.72

>>128
なぜそれレスを俺にするのかよく分からんな
俺は
そんなものはビジネスルールではない
と言っているのだぞ

**デフォルトの名無しさん** · 2016/09/23(金) 13:37:43.52

>>129
そういう制約はビジネスルールに入る場合も多いが
単純に数値であるという字句的な制約はビジネスルールとは独立したものだ

**デフォルトの名無しさん** · 2016/09/23(金) 13:45:53.84

>>130
よくわからんこと言ってるけど、例えば正規表現で簡単にフィルターできる、
「ユーザーIDは半角英数字で8～20文字、ただし先頭の文字は半角英字のみ」
だって立派なビジネスルールだ。

**デフォルトの名無しさん** · 2016/09/23(金) 13:49:14.26

画面に配置する度にテキストボックスに何が入力されるのかを判断してデザイナから正規表現を設定したりLoadイベントで検証オブジェクトを注入したりはめんどくさい
型が分かってるなら○○型用テキストボックスを作って配置するだけにした方が簡単だと思う
でもなんとなくUIが知識を持ちすぎてるように感じて気持ちは良くない

**デフォルトの名無しさん** · 2016/09/23(金) 13:49:46.76

>>132
こう言えば分かるか
ビジネスルールが興味があるのはあくまでもValue
UIコントロールが制御するのはValueとして評価される前のTextのValidation

**デフォルトの名無しさん** · 2016/09/23(金) 13:52:03.90

>>134
まったくわからない

**デフォルトの名無しさん** · 2016/09/23(金) 13:58:45.95

>>135
そうか、じゃあこれはどうだ
ユーザーが入力したものはあくまでもキャラクタコードの羅列にすぎない
当然ビジネスロジック側が扱える値として評価出来ないようなデタラメなものも含んでいる
それをビジネスロジックが望む値として評価出来るようにするまでがUIコントロールのもつ役割

それ以降の値の持つ意味的な制約をコントロールするのはビジネスロジックの仕事

**デフォルトの名無しさん** · 2016/09/23(金) 14:08:32.32

>>136
言いたいことはわからないでもないが、例えば現実の問題としては
入力したユーザーIDが不適切な場合はダイアログのOKボタンをクリックする前に
ErrorProviderか何かで通知するか、そもそも入力できないようにして欲しい、
という要望があったりする。

繰り返しになるけど、そもそも論として、ビジネスロジック側がUIに依存したらおかしいが、
UIがビジネスロジックに依存しても何もおかしくない。

**デフォルトの名無しさん** · 2016/09/23(金) 14:17:08.23

>>137
いや俺が言ってるのはどっちが依存したら良いとか悪いではなくて
validationにもUI側が受け持つべき部分とビジネスロジック側が受け持つべき部分の
2種類あるという事だ
そして元々>>118が言ってる商品コードを表す文字列のルールはUI側が受け持つべき部分であり
ビジネスロジック側が扱うのは商品コードとして有効な値に評価された後でよい
という事な

**デフォルトの名無しさん** · 2016/09/23(金) 14:18:54.66

>>136
ビジネスロジックが求める形式はビジネスロジックしか知らないはずだけど

**デフォルトの名無しさん** · 2016/09/23(金) 14:20:55.08

入力項目をファクトリから生成するようにして
ロジックの配下におけばいい

**デフォルトの名無しさん** · 2016/09/23(金) 14:22:49.17

>>139
うーん
ビジネスロジックが知っているのは値の持つ意味
特定の文字列が特定の形式、これはむしろクラスと考えても良いが
に合致するかどうかってのはビジネスロジックが知る必要はない

**デフォルトの名無しさん** · 2016/09/23(金) 14:31:36.51

>>141
コード値のプレフィックスを見て処理を分岐するとか
文字列の形式がビジネスロジックに影響する例は探せばいくらでもあると思うけど？
もちろんプログラム設計が悪いとかじゃなくそういう要件が現実にあるって話で

**デフォルトの名無しさん** · 2016/09/23(金) 14:34:06.56

>>138
そんな分類はプログムを綺麗に書きたいプログラマ側の都合に過ぎないよ。
何の意味もない。
ユーザーから見たら怠惰なプログラマのただの身勝手に過ぎない。

**デフォルトの名無しさん** · 2016/09/23(金) 14:38:06.66

>>142
その例の場合は、たまたま、というか確かに現実的に多用される手法だけど

値の意味を文字列の形式で表わす様に設計されたコードである

為にロジック的に文字列の形式を評価して分岐しているように見えるというだけで
原則的にビジネスロジックが判断してるのは値の意味なんよ

**デフォルトの名無しさん** · 2016/09/23(金) 14:38:15.25

今時webのUIだって、入力した値が不適切なら入力した段階で教えてくれるよね。

**デフォルトの名無しさん** · 2016/09/23(金) 14:39:23.90

>>143
おいおいプログラムを綺麗に書きたくて議論してたんじゃないのかよw

**デフォルトの名無しさん** · 2016/09/23(金) 14:42:38.64

>>146
こちらはプログラムを綺麗に（可読的かつ後の修正に耐えるように）
UIがビジネスロジック側から提供される入力検証用のロジックを参照せよと言っている。

君が言っているのは、そもそもUI側でビジネスロジックべったりの入力検証なんかするなという話。
それはただの現実の要求を無視したただの怠惰だ。

**デフォルトの名無しさん** · 2016/09/23(金) 14:47:02.61

>>147
別にお前の意見
> UIがビジネスロジック側から提供される入力検証用のロジックを参照せよ
これを批判するような事を言ってるつもりは全くないのだが
なんか言い方が悪かったか？

**デフォルトの名無しさん** · 2016/09/23(金) 14:48:40.29

>>144
たまたま文字列じゃなくて
まんまドキュメントにナントカのIDは先頭がこの文字で何桁のハイフン区切りでハイフンの後ろを取り除いたら親ナントカのIDに一致する文字列ですみたいなことが書いてあったりする
これはプログラミングで必要だからそうなったものではなく実際にエンドユーザーがそういう認識でナントカIDを認識、運用している
これはどうみたって見た目の問題じゃなくビジネスロジックじゃないかな？

**デフォルトの名無しさん** · 2016/09/23(金) 14:49:56.75

>>148
じゃあ延々何を言ってるわけ？w

**デフォルトの名無しさん** · 2016/09/23(金) 14:54:34.72

>>149
うん、ユーザーは字句表現と値の意味を区別するって意識がそもそもないからな
でも開発者はそこから字句表現と値の意味を分離してビジネスロジックの本来的な意味を
読みとらないとゴチャゴチャと整理されないままの融通の利かないいわゆる
「使えないシステム」が出来あがる

**デフォルトの名無しさん** · 2016/09/23(金) 14:58:31.27

>>150
少し話が展開しすぎたから俺もよくわからんw

**デフォルトの名無しさん** · 2016/09/23(金) 17:47:43.12

>>137
>UIがビジネスロジックに依存しても何もおかしくない
別にお前の意見に意義があるわけでなないんだが
UIパーツ(全体としてのUIではなく、あくまでUIを構成するパーツな)の再利用性についてどう考えてるのか教えてくれ

**153** · 2016/09/23(金) 17:51:38.54

×意義
○異議
な。意義がないとか、全否定してるみたいだから訂正しとく

**デフォルトの名無しさん** · 2016/09/23(金) 18:00:12.62

>>153
もう書いてますよ>>128

汎用的に作った方がいいか、どの程度汎用性を持たせるかはケースバイケース。
別に一つの目的にしか使えないコントロールがあっても何も悪くない。

**デフォルトの名無しさん** · 2016/09/23(金) 18:04:25.83

>>152
お前の意見はビジネスロジック以前の単純なチェックはUI自身でやらせろってことだと思うが
じゃあ、ビジネスロジックにかかわる入力チェックを行うUIパーツはどうあるべきだと思うの？