[seasar-dotnet:2450] Re: サンプルプロジェクトの疑問

志水正幸 [E-MAIL ADDRESS DELETED]
2015年 3月 24日 (火) 01:35:32 JST 

志水です。
超お世話になっております。

taknb2nchさんこんばんわ。

> 作っちゃってますね。
> 基本は自作のジェネレータでDtoとConverterを生成しています。
> 特殊な処理がなければ、
> C#ならListResultBean<>からList<画面Dto>まで1行です。
> (Java8ならできそうですね)
ふぇーー自作ジェネレータですか、すごいなぁ！
それならDTOで全部のプロパティ作ってもいいかと思ってしまう・・




> taknb2nchです。
>
>> やっぱお手製でDTOつくってるんですかね？
> 作っちゃってますね。
> 基本は自作のジェネレータでDtoとConverterを生成しています。
> 特殊な処理がなければ、
> C#ならListResultBean<>からList<画面Dto>まで1行です。
> (Java8ならできそうですね)
>
>> 詰め替え処理の実装は、Koropokkur.NETがあります。
> ある時から私の環境ではVS上で動かないんですよねー。
>
>> DBFluteというかぼくのポリシーがありまして...
> 私は同意です。
>
> 2015年3月23日 22:26 kubo <dbflute ＠ gmail.com>:
>> 久保(jflute)です
>>
>>> やっぱお手製でDTOつくってるんですかね？
>> 作っちゃってますね。
>> Eclipseの補完とかも便利になって、
>> Getter/Setterを作るコストも気にならなくなりましたし、
>> C#ならpropertyがあって、Javaでもpublicフィールド使っちゃったり。
>> 一行コピーのショートカットを使っていけば、
>> ほぼ名前を打つだけに等しい感じなので。
>>
>> ただ、気持ちはわからなくはないので参考までに。
>> 画面項目定義書から自動生成してる現場もありました。
>> また、Javaではありますが Ymir というフレームワークでは、
>> HTMLテンプレートからDtoが自動生成されました。
>> (Teedaでも最初の一回だけはDoltengで自動生成できた)
>>
>> そして、詰め替え処理の実装は、Koropokkur.NETがあります。
>> http://koropokkur.net.sandbox.seasar.org/copygen.html
>>
>> ここはまあ、DBFluteというかぼくのポリシーがありまして...
>> http://dbflute.seasar.org/ja/tutorial/architect.html#entityset
>>
>> ※Ymirでも、詰め替え処理のConveterが自動生成されまていました。
>>
>>
>>> JSPと違い、ASP.NETだと画面へ渡す箇所で変更があった場合は検知できますね。
>>> 属性が変わった場合も大概エラーになるし。
>> 最近のASP.NETがわからないのですが、
>> これってVisualStudio上でコンパイルエラーになるってことでしょうか？
>> (e.g. DBFluteで自動生成してカラム名変わっていたら、即座にコンパイルエラー？)
>>
>> もしそうあれば、疎結合とか考える必要がないのであれば、
>> 無理してDtoに詰め替える必要はないかもですね。
>>
>>
>>
>>
>> 2015-03-23 21:52 GMT+09:00 志水正幸 <ie2m-smz ＠ asahi-net.or.jp>:
>>> 志水です。
>>> 超お世話になっております。
>>>
>>>
>>> taknb2nchさん、こんばんわ。
>>> 貴重なご意見ありがとうございます。
>>>
>>>
>>>> 私もMemberDto（ビュー用）にMember（DBFluteのエンティティ）を継承させることはしません。
>>>> 当然ながらDto内にエンティティのインスタンスを保持することもしません。
>>>> JavaであろうがC#であろうが、
>>>> 各レイヤー間ができるだけ疎結合になるように意識しています。
>>>
>>> オブジェクト指向の考えですね。
>>> 私も一応なんとなく分けなきゃくらいは意識してるんですけどね（笑）
>>> やっぱお手製でDTOつくってるんですかね？
>>>
>>> 今回のDTOの話でいくとまるっと作らなきゃならいないので
>>> 意識するのはいいけど、逆に生産性が落ちやしませんか？
>>> １０も２０ものテーブルのDTOモジュール作ったり
>>> テーブルカラムの数なんて３０，４０個なんてざらにあるし。
>>> テーブル変更したら、変更箇所の修正が必要で
>>> 気が遠くなりそうだし、
>>> ちょっと継承するだけだから、ちょっとくらいいいやと思ってました。
>>> 「疎結合」ってツライなぁ・・・
>>> しんどいの嫌だからつい楽な方にいっちゃうのがダメなのかな（笑）
>>>
>>>
>>>> ある日突然、
>>>> 「DBFlute使用禁止！他のORMに変更しろ！」
>>>> とか言われたどうします？
>>> あー、そもそもがお客の環境に合わせてつくるので
>>> それは考えたことなかったです。。
>>> それに一人開発なので誰にも指示受けないので。
>>> 一般のソフトハウスなら急なお客の都合で営業が負けて
>>> 帰ってくるとかあるかもですね。
>>>
>>> でももし、使うなと言われれば継承元のクラスを別途作るか
>>> 継承やめてDTOに残りのプロパティ追加して
>>> DBアクセス部分もそれに合わせて別途作って
>>> 画面の基底クラスに配置すればできないこともないかな？
>>> あーでもSQLつくるのめんどくさいー
>>> ただ、本当に言われたら
>>> DBFLUTEの便利さがわかってるだけにやっぱ困りますね（笑）
>>> そんなお客の仕事は、無理にでも押し通すか断っちゃうかも（笑）
>>>
>>>
>>> いやー、やっぱり人の意見は聞くもんですね。
>>> 「疎結合」は今回改めて意識させられました。
>>> 普段なんとなく分けなきゃくらいにしか思ってなかったので。
>>> 有難うございました。
>>>
>>> でもどうしよう。作るのしんどい（笑）
>>>
>>>
>>> 他にどなたか良いご意見など
>>> お待ちしております～
>>>
>>>
>>>
>>>> taknb2nchです。
>>>>
>>>>
>>>> 簡単に少しだけ書かせていただきます。
>>>>
>>>> 私もMemberDto（ビュー用）にMember（DBFluteのエンティティ）を継承させることはしません。
>>>> 当然ながらDto内にエンティティのインスタンスを保持することもしません。
>>>>
>>>> JavaであろうがC#であろうが、
>>>> 各レイヤー間ができるだけ疎結合になるように意識しています。
>>>>
>>>>
>>>> 極端な例ですが、
>>>>
>>>>> あーでも、DB自体がORACLE⇔SQLSERVERとかに変わったりした場合とか
>>>>> 直接参照しているといろんな使用箇所毎で影響あるかもですね。
>>>>> これが一番怖いですね。
>>>> と書かれていますが、
>>>> ある日突然、
>>>> 「DBFlute使用禁止！他のORMに変更しろ！」
>>>> とか言われたどうします？
>>>>
>>>> （こんなこと言われたら私も困りますが）
>>>>
>>>>
>>>>> １０も２０ものテーブルのDTOモジュール作るのって結構大変だし。
>>>>
>>>> あくまで個人的な考えです。
>>>>
>>>> 2015年3月23日 18:54 志水正幸 <ie2m-smz ＠ asahi-net.or.jp>:
>>>>> 志水です。
>>>>> 超お世話になっております。
>>>>>
>>>>>
>>>>> 久保さんこんばんわ。
>>>>> 御意見ありがとうございます。
>>>>>
>>>>>> いいんですよー、でなければseasar-dotnet閑古鳥になってしまいますから。
>>>>>> 今回みたいに「みんなどう作ってる？」っての、もっと共有していきたいですね。
>>>>> そう言っていただけるだけで安心です。。。
>>>>> 一人で開発していると誰にも意見やアドバイスがもらえないので
>>>>> 色々と仕組みに関しての悩み所が多くて、迷惑かなと思いつつ質問してます。。。
>>>>> C#むずいし、汎用時代のCOBOLが一番簡単だったなぁ・・
>>>>>
>>>>>> リストを別のにするっていうよりかは、
>>>>>> DBのEntityを直接HTMLテンプレートに渡さないっていうことは意識しています。
>>>>>> (普段Javaなので、その場合はJSPになります。JSPからEntityの直接参照は禁止)
>>>>>>
>>>>>> なぜかというと、DBの変更があったときにコンパイルエラーで検知しやすいという
>>>>>> メリットでDBFluteがあるわけですが、コンパイルセーフでないHTMLテンプレートに
>>>>>> Entityを渡してしまうとい、変更があってもコンパイルエラーで検知できないからです。
>>>>>>
>>>>>> そう言う意味では、MemberDtoにMemberを継承させるってのも、
>>>>>> ぼくはやらないですね。
>>>>>>
>>>>> なるほど、JSPだと確かにカラムや属性変更があっても、
>>>>> 実際に動かすときにコンパイルされるわけだから箇所がわからないですね。
>>>>> 特に属性とかもみてもいないんでしたっけ？
>>>>> DBのEntityを直接渡さないというのも、そういう理由ならわかりますね。
>>>>>
>>>>> けど、新たに別のDTO作ってやるのって結構大変ですね。
>>>>> みんなお手製なんですか？
>>>>> ツールとかあればっていつも思ってしまうんです（笑）
>>>>> 自動で作るツールをつくろうと思ってもスキルないので無理（笑）
>>>>> 最近、dynamicや<T>とかでクラス指定できるんだって知ったばかりなので。。
>>>>> ずっとOBJECT使ってキャストしてました（笑）
>>>>>
>>>>> MemberDtoにMember継承させてやるような仕様にしている私でも
>>>>> コピーメソッド作るのがあまりにも大変だったし、
>>>>> 変更したら手直しいるしで、今回からAutoMapperでポイッとコピーしてます。
>>>>>
>>>>> JSPと違い、ASP.NETだと画面へ渡す箇所で変更があった場合は検知できますね。
>>>>> 属性が変わった場合も大概エラーになるし。
>>>>> この辺は言語仕様の違いなので、.NETは別のリスト作らなくてもいいような気もするけど
>>>>> 今はDBアクセスなどはLogicクラス介してILISTのDTOを返却するような形にしていて
>>>>> 一応の切り分けをしているので、
>>>>> なんか、今更DBのEntityを直接使用するのはちょっと気持ち悪い気もするし
>>>>>
>>>>> あーでも、DB自体がORACLE⇔SQLSERVERとかに変わったりした場合とか
>>>>> 直接参照しているといろんな使用箇所毎で影響あるかもですね。
>>>>> これが一番怖いですね。
>>>>>
>>>>> ちょっと生産性的や稼働には非効率だけれども
>>>>> 保守的なことを考えると
>>>>> DTOに一旦渡すやり方が、一元管理もできるし良い気がしてきました。
>>>>> でも全部お手製はいやなので、MemberDtoにMemberを継承すような方法で
>>>>> カラム単位で影響がでた場合は
>>>>> MemberDtoに影響あるカラムをあれコレする手法がいいかな～
>>>>>
>>>>> うちはこんなやり方で生産性や保守を効率的にしている～
>>>>> とか、いやこんなやり方は邪道だーとか
>>>>> あまり難しいことはわからないのですが
>>>>> ご意見などご教示しただければと思います。
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 久保(jflute)です
>>>>>>
>>>>>>> 　  返却されてきたPagingResultBeanをそのまま使った方が効率いいように思うの ですが
>>>>>>> 　  サンプルの「dbflute.net-asp.net-example」はなぜ、一旦別のリストに移し 替えているのでしょうか？
>>>>>> リストを別のにするっていうよりかは、
>>>>>> DBのEntityを直接HTMLテンプレートに渡さないっていうことは意識しています。
>>>>>> (普段Javaなので、その場合はJSPになります。JSPからEntityの直接参照は禁止)
>>>>>>
>>>>>> なぜかというと、DBの変更があったときにコンパイルエラーで検知しやすいという
>>>>>> メリットでDBFluteがあるわけですが、コンパイルセーフでないHTMLテンプレートに
>>>>>> Entityを渡してしまうとい、変更があってもコンパイルエラーで検知できないからです。
>>>>>>
>>>>>> そう言う意味では、MemberDtoにMemberを継承させるってのも、
>>>>>> ぼくはやらないですね。
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 最近、私ばかり質問しているようで恐縮してしまうばかりで
>>>>>>> なんか本当にすいません。
>>>>>> いいんですよー、でなければseasar-dotnet閑古鳥になってしまいますから。
>>>>>> 今回みたいに「みんなどう作ってる？」っての、もっと共有していきたいですね。
>>>>>>
>>>>>> 2015-03-23 13:25 GMT+09:00 志水正幸 <ie2m-smz ＠ asahi-net.or.jp>:
>>>>>>> 志水です。
>>>>>>> 超お世話になっております。
>>>>>>>
>>>>>>>
>>>>>>> 最近、私ばかり質問しているようで恐縮してしまうばかりで
>>>>>>> なんか本当にすいません。
>>>>>>>
>>>>>>> 元々、初めてのC#とASP.NETのダブルの独学だったので
>>>>>>> あまり細かいところに意識が回らなかった私が悪いですが
>>>>>>> 今回、新たにプロジェクトを作成した際にマニュアルやサンプルを見なおしていて
>>>>>>> 自分の使い方が正しいのかどうかがよくわからなくなりました。
>>>>>>> ※サンプルは　　「dbflute.net-quill-example」　　「dbflute.net-asp.net- example」
>>>>>>> を見ていました。
>>>>>>>
>>>>>>> 現在のプロジェクトを作成するにあたり参考にしたのが
>>>>>>> サンプルの「dbflute.net-asp.net-example」で
>>>>>>> このプロジェクトには
>>>>>>> 「DfExampleBiz」プロジェクトに
>>>>>>> 「Facade」 > 「Dto 」
>>>>>>>     MemberDto
>>>>>>>     MemberDtoList
>>>>>>> が作成されておりまして、これらを使って画面に表示させるような仕組みでした。
>>>>>>> 今までやってきたJavaとかは、普通にBeanとか手作りだったので
>>>>>>> これが普通にしっくりきたんですね。
>>>>>>>
>>>>>>> サンプルを真似して、今のプロジェクトは
>>>>>>> 「ExEntity」のMemberを継承させたMemberDtoを作成しています。
>>>>>>>
>>>>>>> **************************************************************************************
>>>>>>> ↓↓↓こんな感じです。↓↓↓
>>>>>>> PagingResultBean<DfExample.DBFlute.ExEntity.Member> page =
>>>>>>> memberBhv.SelectPage(cb);
>>>>>>>               list.AllRecordCount = page.AllPageCount;
>>>>>>>
>>>>>>>               foreach (var member in page)
>>>>>>>               {
>>>>>>>                   MemberDto dto = new MemberDto();
>>>>>>>
>>>>>>>                   ここで、全プロパティをコピー
>>>>>>>
>>>>>>>                   list.MemberList.Add(dto);
>>>>>>>               }
>>>>>>>
>>>>>>> **************************************************************************************
>>>>>>>
>>>>>>> また、InsertやUpdate、DeleteのメソッドにはMemberに移し替えることはせず、
>>>>>>> MemberDto をそのまま渡しています。
>>>>>>>
>>>>>>>
>>>>>>> ＜疑問点＞
>>>>>>> 　  まだまだ、よくわかってないことがいっぱいあるので変なこと言っているかも しれないのですが
>>>>>>> 　  返却されてきたPagingResultBeanをそのまま使った方が効率いいように思うの ですが
>>>>>>> 　  サンプルの「dbflute.net-asp.net-example」はなぜ、一旦別のリストに移し 替えているのでしょうか？
>>>>>>> 　  みなさん、どのような仕組みされていますか？
>>>>>>>
>>>>>>> 以上、ご教示お願いします。
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---
>>>>>>> このEメールはアバスト アンチウイルスによりウイルススキャンされています。
>>>>>>> http://www.avast.com
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> seasar-dotnet mailing list
>>>>>>> seasar-dotnet ＠ ml.seasar.org
>>>>>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>>>> _______________________________________________
>>>>>> seasar-dotnet mailing list
>>>>>> seasar-dotnet ＠ ml.seasar.org
>>>>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>>>>
>>>>> _______________________________________________
>>>>> seasar-dotnet mailing list
>>>>> seasar-dotnet ＠ ml.seasar.org
>>>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>> _______________________________________________
>>>> seasar-dotnet mailing list
>>>> seasar-dotnet ＠ ml.seasar.org
>>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>
>>>
>>> ---
>>> このEメールはアバスト アンチウイルスによりウイルススキャンされています。
>>> http://www.avast.com
>>>
>>> _______________________________________________
>>> seasar-dotnet mailing list
>>> seasar-dotnet ＠ ml.seasar.org
>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>> _______________________________________________
>> seasar-dotnet mailing list
>> seasar-dotnet ＠ ml.seasar.org
>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
> _______________________________________________
> seasar-dotnet mailing list
> seasar-dotnet ＠ ml.seasar.org
> https://ml.seasar.org/mailman/listinfo/seasar-dotnet


---
このEメールはアバスト アンチウイルスによりウイルススキャンされています。
http://www.avast.com

seasar-dotnet メーリングリストの案内