【Java】 Java Web Ap ..
180:デフォルトの名無しさん
13/01/27 18:21:36.77
つ URLﾘﾝｸ(www.infoq.com)
181:デフォルトの名無しさん
13/01/27 21:55:42.86
>>180
読んでみたけど全体的に JAX-RS の方が美しく感じる。
・レスポンス
・Conneg
・例外ハンドリング
あたりは JAX-RS の方が良いと思った。けど実用性は多分 Spring MVC なんだろうな・・・。
各 JAX-RS 実装の拡張が色々あるから実際にアプリつくるときにあまり困ることはそんなに無いと思うんだけど、やってみないと分からないなー。
でもまぁ flush スコープとか validation とかあるからやっぱり Spring MVC なのかな・・・。
182:デフォルトの名無しさん
13/01/28 02:37:48.31
>>179
JPAについてコメントします。
JPAは規格の名前で、Toplink Essentialsは、JPAの実装の一種です。
いちおう、TopLinkが JPA のリファレンス実装となっています。
JPAの実装のオープンソースは、ほかに
OpenJPA、Hibernate(Hibernate EntityManager) などがあります。
あと、
> Javaで使用率高いORMは、JPAとTopLink Essentialsの組み合わせかな？
> 両方オラクル純正だし
Javaの世界でオラクル純正は、あまりアテになりません。
Oracle(Sun)純正でクソなプロダクトは、これまでにもいくらでもありました。
おまけ：
このプログラム板に以下のスレがあります。
Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.5
ｽﾚﾘﾝｸ(tech板)
その昔は、Javaの各ORマッパーについての議論が活発で、
とても勉強になるスレだったのですが、ここ数年は
全然関係ないアニメのコピペが貼られるだけになってしまいました。
残念です(まぁJavaのORマッパーの話題は、一通り行き着くところまで行ってしまったのかもしれないが)
183:デフォルトの名無しさん
13/01/28 02:41:01.19
>>179
もう少しだけ補足。ご存じだったらすみません。
> JavaのORM = Hibernate = XMLマッピング地獄だと思ってた。
初期のHibernateは、そのとおりXMLマッピング地獄だったけど、
Hibernate Annotations というのができて、Enittyクラスにアノテーションでカラム名とか付けられるようになった
(XMLに書かなくても良くなった)
さらに Hibernate EntityManager というのができて、Hibernate が JPA をサポートするようになった。
184:>>20
13/01/28 21:39:34.15
かなり古いバージョンの記事が検索の上位にかかりやすいよね。
ちなみにJPAと同じ要領でXMLをマッピングするJAXBなんてのもあるぞ。
185:デフォルトの名無しさん
13/01/31 14:25:30.71
URLﾘﾝｸ(www.infoq.com)
Plans for Spring Framework 4.0 Announced
- Includes Support for Java SE 8 and Groovy 2
186:デフォルトの名無しさん
13/02/02 17:40:16.89
もうダメだわｗ
Twitterサイバーテロ事件の原因は話題のJavaの脆弱性ｗｗｗｗｗ 今すぐアンインストールしろｗｗｗｗｗ
ｽﾚﾘﾝｸ(poverty板)
187:デフォルトの名無しさん
13/02/02 22:30:37.53
昔Jerseyを使ったときにJAXBでアノテーションつけたbeanをJSONにシリアライズして
レスポンスとして返す場合に、プロパティに配列やコレクションがあるとその要素数に
よってそのプロパティのシリアライズの結果がArrayになったり裸単騎の値になったりして
頭を抱えたのだけれども今は大丈夫なんだろうか。
188:デフォルトの名無しさん
13/02/02 23:13:34.40
XML地獄の次はアノテーション地獄か
昔のJavaが一番作りやすかったな
いまは新入社員が入ってくる余地がないな
189:デフォルトの名無しさん
13/02/03 17:15:48.97
裸単騎ｗ
190:デフォルトの名無しさん
13/02/06 14:28:49.36
>>187
MessageBodyWriter使ってjsonicあたりに処理させればいいんじゃないの
191:デフォルトの名無しさん
13/02/07 00:34:05.94
アノテーションが増えてソースコードがXMLみたいになるな。
言語やＦＷを変化させても冗長性と簡略化のトレードオフになるだけで
優れたものに前進しないな。
192:デフォルトの名無しさん
13/02/07 13:38:09.81
そこで設定より規約ですよ
193:デフォルトの名無しさん
13/02/07 13:43:15.61
rubyやphpのほうが作りやすいということ
Javaは方向性間違ったな
194:デフォルトの名無しさん
13/02/07 14:48:22.64
COCはフレームワークの話だろ。
Playとかあるじゃん。
ArrayList, HashMapは構文に組み込んで欲しい。
あとアノテーションプロセッサを使いやすくできれば
COC方面で著しい変化がある。
var array = new Integer[];
var hash = new [String, Integer];
195:デフォルトの名無しさん
13/02/07 16:37:04.64
JAXBやJPAのアノテーションの話であれば十分にCoCしていると思うけれどもね。
普通のBenasであれば冒頭にただ@Entityとか@XMLRootElementとか書いておけばあとは何も
せずとも規約に従って大体よろしくマッピングしてくれる。
ただ規約に外れて手作りししたい部分が出てくるとその程度によってアノテーションだとかえって
見通しが悪くなることがあるのも事実。
196:デフォルトの名無しさん
13/02/07 20:26:49.56
「規約と完全一致ならBeanクラス自体がなくてもいい。」
アノテーションプロセッサでここまでできればRailsに勝てるだろう。
IDEにスケルトンプログラムのジェネレータプラグイン入れて
クラスファイルの山を作ってるのが現状。
今度はコンパイルが重くて仕方ないか。
197:デフォルトの名無しさん
13/02/08 01:48:59.44
Rails(というかActiveRecord)の便利なところは、
モデルクラスにメソッドを定義してなくても、呼び出し側が適当なメソッド名を
呼んでしまえば、Method Missing により、規約に沿って自動的に解釈されてSQLを実行してくれるところだと思う。
コンパイル言語でのJavaでは、これは絶対に無理。
S2Daoなど、Interfaceだけ定義すれば proxy オブジェクトを作ってくれるフレームワークはいくつかあるけど、
かならず Interface にメソッドだけは定義しないと行けないし。
198:デフォルトの名無しさん
13/02/08 02:18:23.89
本当に無理なんかなあ。Javaって回り道ばかりしてるじゃん
生活費1000万くれて1年それだけに集中していいって言われたら
開発者みんなが楽できる最強のフレームワーク作れる自信あるわ
199:デフォルトの名無しさん
13/02/08 05:10:55.98
最強のフレームワークなら１０００万円以上で売れるんじゃね？
200:デフォルトの名無しさん
13/02/08 07:11:01.57
Beans無しでしかも型安全なフレームワークが実現可能ならまだ存在意義もあるだろうけれども
Beans無しというだけでは全く流行らないだろうね。
201:デフォルトの名無しさん
13/02/08 14:27:57.43
>>198
コンセプトだけプレゼンしてみ？
よさげならうちの職場に紹介するよ
1年1千万なら余裕で出せるはず
202:デフォルトの名無しさん
13/02/08 15:22:57.86
Beans無しがそんなに嬉しいかねぇ。
203:デフォルトの名無しさん
13/02/08 16:00:08.22
>>200 >>202
Beansってなんのこと？
Entityクラスを作るってこと？
(SpringMVCにおける、Form の Modelクラスでもいいけど)
204:デフォルトの名無しさん
13/02/08 16:19:47.38
そういうことじゃね?
厳密にはEntityクラスは作るにしても、ActiveRecordだけ継承すればあとはフィールドや
アクセサの類を定義しない空のクラスのままでもよろしく動くということだと思う。
205:198です。
13/02/08 21:19:31.37
star-123@yahoo.co.jp
メール下さい。
206:198
13/02/08 23:00:45.38
早くメール下さい。
207:デフォルトの名無しさん
13/02/08 23:38:25.89
１０００万の仕事を捨てメアドで募集してるときいて
208:196
13/02/09 01:13:47.47
アノテーションプロセッサができるのはコンパイル時クラスの自動生成だよ。
Javassistとかは実行時生成だからインターフェースとか必要になるけど、
アノテーションプロセッサだとソース上では全く定義されていないクラスを
new HelloBean();とかしても型安全に操作できる。
今のアノテーションプロセッサでＦＷはかなり作りづらいし、見向きもされていない。
209:デフォルトの名無しさん
13/02/09 02:08:32.22
>>208
型安全… だと？
HelloBeanじゃなくHalloBeanと書いた場合にどうやって間違いを見つけるんだ？w
210:デフォルトの名無しさん
13/02/09 03:06:41.17
コンパイル時にターゲットのDBに接続してスキーマ引っ張ってくる必要があるな。
211:デフォルトの名無しさん
13/02/09 03:13:38.12
アノテーションプロセッサを使うというのは、(webフレームワークではなくORMだけど)Domaも似たようなものかな。
Interfaceクラスだけつくって、アノテーションプロセッサを一度実行しないといけないけど、Entityクラスが自動生成されるのはいいかも。
でも、それって Excel などでつくったプロジェクト内自動生成ツールを事前に実行するのと、手間的には変わらない気もする。
212:デフォルトの名無しさん
13/02/09 03:23:31.64
DBから生成できるEntityのプロパティはアノテーションプロセッサで作る必要ないな
>>197が言ってるのはSQL生成するメソッドだから、O/Rマッピングパターンだと
存在しないDAOを呼び出すとアノテーションプロセッサが作ってくれるイメージだろ
213:デフォルトの名無しさん
13/02/09 09:38:16.20
自動生成してくれるのは結構なんだがきっちりドメインオブジェクトを書き起こさずに
メソッドの自動生成に任せていて開発規模的にどの程度スケールするのかは気になる。
214:196
13/02/09 12:41:01.52
railsみたいにcocでもりもり削ろうぜって話だったはず
215:デフォルトの名無しさん
13/02/09 16:45:23.43
マイグレーションや関連、検証を書き始めるとあまり変わらん気もする。
JPA等を使うにしても結局面倒なのはそこで、Beansの定義自体は機械的作業でIDE使えば
面倒でも何でもないし、むしろBeansが無かったり動的生成されるほうが静的検証もやり
にくいしむしろ色々面倒臭い。
216:デフォルトの名無しさん
13/02/09 17:55:05.13
Eclipseが標準でSQLJを手厚くサポートしていればいろいろ違ったかもな
217:デフォルトの名無しさん
13/02/09 22:10:06.33
ORMの話だしSQLJ等の埋め込みクエリはあまり関係ないかなぁ。でもJPQLは好き。
ORMを使っていても集約計算などするときは変にエンティティオブジェクトや
フレームワークが提供する無駄に独自性溢れるクエリーAPIと格闘するよりSQL一本
書いた方が速いよね、という場面はそこそこあるし、そういった場合にはJPQLは
DBMSの方言を気にせずハードコード出来てかつどんなSQLが吐かれるか大体見当が
つくので個人的には時々便利に使う。
218:デフォルトの名無しさん
13/02/09 22:37:44.53
ORMったってマッピングの部分はほぼ完成していて問題にならない。
問題なのは相変わらずクエリを作るところだろ。
JPQLもクライテリアAPIもそこじゃん。
そこの標準が早期(JDK1.1)からあったんだからIDEがしっかりサポートしていれば
もっといろいろな発展があったと思うね。
OracleのSQL Developer使ったことあればわかるだろうけど、エディタ上でSQL書くと
その場で文法に加えて名前や型までチェックされて、即実行して結果も見える。
あれがJavaとシームレスにつながって関係するDAOやJavaBeansが自動生成されれば
相当便利なものになったんじゃないか。少なくとも、その基礎にはなり得たんじゃないか。
219:デフォルトの名無しさん
13/02/09 22:51:10.17
JSQLとJPQLライクの間みたいのが素敵だと思う。
jpql {
..Result<Entity> result = query {
....Entity e,
....From e,
....Bool isA = e.price > 0 && e.price < 100,
....Bool isB = e.price > 1000 && e.price < 2000,
....Where isA || isB,
....Order e.name,
....fetch lazy
..};
..List<Entity> list = result.range(first, last);
};
220:デフォルトの名無しさん
13/02/09 23:14:58.74
っていうか、こういう話を↓のスレで続けたかったな。
最初の頃はとても勉強になるスレだったのに、いまは変なアニメの人が居着いちゃってとても残念。
Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.5
ｽﾚﾘﾝｸ(tech板)
221:デフォルトの名無しさん
13/02/09 23:26:28.54
そのスレまだ蹂躙されてたのかw
222:デフォルトの名無しさん
13/02/11 17:04:04.35
アニメの話はアニメ板でやった方が
反応もあって楽しいだろうに何であそこなんだろうな。
223:デフォルトの名無しさん
13/03/02 14:27:18.78
アニメ好きのJavaでDB開発担当してたやつが
仕事で下手こいてクビになったとか、メンタル壊して鬱病ヒキコモリに
なってしまったとか、哀れな末路に驀進中なんじゃね？
別スレ立ててもいいかもね。
そういえば、そのスレの１スレ目立てたの俺だった。。
最近、鯖側でスクリプト環境使うことが増えてきて、今までは
スクリプトは遅いとかバカにしてたけど、即時修正とか
運用のしやすさとかを感じて見直している。
Javaにもこういう扱いやすさが欲しいな。。。
ホットデプロイ使えばいいのか。
224:デフォルトの名無しさん
13/03/02 18:21:24.23
>>223
おお、あなたが Java⇔RDBのMapping-Frameworkを語るｽﾚ vol.1 スレを立てたのか。
乙です。
> 最近、鯖側でスクリプト環境使うことが増えてきて、今までは
> スクリプトは遅いとかバカにしてたけど、即時修正とか
> 運用のしやすさとかを感じて見直している。
今は何を使っているの?
JavaじゃなくてRailsとかPHPとか?
225:デフォルトの名無しさん
13/03/02 18:50:32.40
ポール・グレハム
Wikipedia項目ﾘﾝｸ
は lisp でフレームワークを書いていたというのだから、それもいいかもしれない
226:デフォルトの名無しさん
13/03/04 19:46:02.90
Eclipse統合M34【Java/C++/Ruby/Python/Scala】
ｽﾚﾘﾝｸ(tech板:103-106番)n
↑のスレに質問したところ、こちらのスレが適切ということで、
こちらで質問させて頂きたいです
どなたかよろしくお願い致します
227:デフォルトの名無しさん
13/03/04 22:52:15.49
Javaの入門書を卒業して、サーブレット、JSP、jdbcでのDB操作もできるようになりました。
Webフレームワークを使って、勉強用に簡素なショッピングサイトでも作ってみようかと思ってるのですが、
いま、初めてやるとしたら、どのフレームワークを使うのがいいでしょうか。
228:デフォルトの名無しさん
13/03/04 23:58:37.09
play framework 2.1 がいいと思う
229:デフォルトの名無しさん
13/03/05 04:23:08.94
Grails
230:デフォルトの名無しさん
13/03/06 20:31:46.32
フレームワークなんかなくても、
サーブレットとJSPで作るのが一番正解だよ
231:デフォルトの名無しさん
13/03/06 20:49:59.21
一番迷惑。
規模が大きくなると結局オレオレフレームワークの類を作り始めるので、そうなる前に
ちゃんとしたフレームワークを使って欲しい。
232:デフォルトの名無しさん
13/03/06 21:15:41.74
>>231
ちゃんとしたフレームワークないじゃん
ちょっと特殊なことしようとするとクソハマり
だから>>230が正解
もしくはJavaを捨てる
233:デフォルトの名無しさん
13/03/06 21:27:58.57
>>232
とくしゅなことってどんなw
234:デフォルトの名無しさん
13/03/06 21:35:06.25
それは本当に特殊なのか？
本当に特殊だとして、それは本当に必要なのか？
本当に必要だとして、それは本当に特殊なことをしないと実現できないのか？
235:デフォルトの名無しさん
13/03/06 21:43:27.90
ハマる回数が多すぎていちいち覚えてないよ
フレームワークのサンプルまんまで業務が回るならいいけどそうじゃないだろ
236:デフォルトの名無しさん
13/03/06 21:47:18.97
世の中にあるフレームワークは全てオレオレだからな。
いくつかのシステムと他の言語も経験すれば、「ぼくのかんがえたさいきょうのフレームワーク」を作る能力もつく。
結局それが一番正解に近いのさ。
車輪の再発明こそがプログラマーの醍醐味。
もちろん今あるフレームワークの長所短所も研究するべきだけどね。
237:デフォルトの名無しさん
13/03/06 22:09:52.61
>>229
デモ見るとGrailsはかんたんに扱えそうな感じだね
URLﾘﾝｸ(grails.org)
JavaじゃなくてGroovyになってるから性能が心配なところだけど
実行前にはすべてJavaのバイトコードに事前コンパイルされるのかな？
>>230
ゴリゴリJSPでやるのは生産性が悪いと思う
>>232
例えば今まで何のフレームワークを試したの？
238:デフォルトの名無しさん
13/03/06 22:24:12.80
単にフレームワークを使うだけの力もなかったんだろ
239:デフォルトの名無しさん
13/03/06 22:29:33.88
サンプルからちょっと外れるとクソハマリなんてフレームワークの流儀や
コンセプトを知らずに使ってる証
240:デフォルトの名無しさん
13/03/06 22:53:35.30
フレームワークってその流儀やコンセプトの押し付けがましいのが嫌。
241:デフォルトの名無しさん
13/03/06 22:57:37.87
>>238
力がないと使えないならいらない
servletやjspなら力なんて一切必要ないぞ
242:デフォルトの名無しさん
13/03/06 23:21:15.89
３次元配列が扱えるフレームワーク無いもんなー
使えないよな
243:デフォルトの名無しさん
13/03/06 23:28:15.29
>>241
効率よく作るにはむしろ相当な力が必要じゃね？
それこそ小さな画面一つ作って終わりじゃないだろ
244:デフォルトの名無しさん
13/03/06 23:31:37.49
>>243
そりゃライブラリの類はたくさん必要だよ
でも外から自由を奪いにくるフレームワークは不要
245:デフォルトの名無しさん
13/03/06 23:32:09.71
力ないやつが生servlet/jspで作ったらメンテ不可能なものしかできなそう
246:デフォルトの名無しさん
13/03/07 00:25:47.22
>>244
規模が大きくなってくるとそのうちそのライブラリの中にフレームワークが入ってくるんじゃないのかw
247:デフォルトの名無しさん
13/03/07 00:32:52.10
>>246
入らないよ。ライブラリは実装から呼び出される側、
フレームワークは実装を呼び出す側、役割が全然違う
248:デフォルトの名無しさん
13/03/07 00:42:19.97
匿名で使えるgistでもあればそのライブラリ使ったコード貼ってみろよで終わりなんだけどな
お互い相手を下に見てるどうしが1、2行の文章だけでやりあっても不毛
249:デフォルトの名無しさん
13/03/07 06:14:07.70
>>236
誰も「さいきょうフレームワーク」の醍醐味なんか求めていない。趣味かよ。
オレオレにせよ商用にせよOSSにせよ、今すぐに使えてどれだけ継続的にアップデートが
続くかが問題。
どこかの天才が気まぐれで作ったさいきょうフレームワークよりも沢山のユーザに使われて
ある程度の期間バグを叩かれまくっているそこそこのフレームワークを使うね自分は。
250:デフォルトの名無しさん
13/03/07 08:43:31.29
画面が多いだけの大規模システム（いわゆる業務系）なら
フレームワークも有効だろうねぇ
251:デフォルトの名無しさん
13/03/07 15:56:03.63
「画面が多いだけ」ってよくわからん。
画面が多い「から」、フロントエンドの規模が大きいからウェブアプリのフレームワークを
使うのであって、その後ろに画面の多さ以外の何があろうが別問題だと思うのだが。
上から下まで全部一つのフレームワークで作ることしか頭にないのか。
252:デフォルトの名無しさん
13/03/07 16:10:25.88
でもおまいらの言ってるのは何が何でもフレームワークなんだろ？
とにかくまずフレームワークを使うことが第一であとは
どうでもいいって感じ。
253:デフォルトの名無しさん
13/03/07 16:20:28.86
じゃなくて、Java使ってWAF使って開発すると決めた後の話題が主なのがこのスレ
違う決断した後の話は別スレでする
254:デフォルトの名無しさん
13/03/07 16:24:17.70
JavaとWAF使うってことは型にはめやすい、型にはめるメリットがある(似た画面多い、人が多い)案件って事
そうじゃないこともあるが、それをここで話す意味がわからない
255:デフォルトの名無しさん
13/03/07 16:36:01.22
>>254の「そうじゃないこと」は「そうじゃない案件」です
256:デフォルトの名無しさん
13/03/07 16:43:44.27
>>237
Grailsは実質Spring MVCで、その上に動的言語と名前ベースのCoCの薄皮をかぶせた物だから。
なのでドメインクラスとかサービス層など内側の大事なところはJavaでカッチリ型安全に書いて
おいて、それをGrailsアプリの上にデプロイするのは案外自然に出来る。
そうしておけば重さが気になるのはVCのウェブ層だけの部分になるけれども、ここは開発も実行
も重いよw GroovyもJSPのGroovy版であるGSPも事前コンパイルされるけれども、Groovy
自体が遅い。ただ生産性は高いと思う。GroovyやRubyの経験があればVCは本当に書きやすい。
意外にはまったのが依存性の解決かな。Mavenでなくてivyベースで、Mavenリポジトリから
依存性を引っぱってくることも出来るのだけれども、Mavenとは微妙に振る舞いが違うことも
あってMavenベースのプロジェクトと連携するさいに妙にはまったことがある。
Maven統合プラグインもあるのだけれども評価時にはイマイチで以後使っていない。
257:デフォルトの名無しさん
13/03/07 18:23:53.38
>>256
Grailsって、ORMはHibernateを同梱しているんだよね？
Hibernateあまり使いたくないんだよなぁ。
MyBatisなどに差し替えられないの？
258:デフォルトの名無しさん
13/03/07 18:36:40.23
>>257
Mを構成するGORMというORマッパーはJPAどころかがっつりHibernateに依存しているので
無理っぽい。WAR等からHibernateだけ切り離すのも無理じゃないのかな。
ただ別のORMで書かれたMをVCから叩くのは普通に出来ると思う。たぶん。
259:デフォルトの名無しさん
13/03/07 18:39:36.67
>>256
ありがとう。
CoCが魅力的だったけど、速度も重視したいからSpring MVCも見てみる。
GrailsはJavaでも書けるようになってほしいな
260:デフォルトの名無しさん
13/03/07 18:46:34.27
やっぱり不自由が発生してるじゃん
Aだけを使いたいのに使いたくないBまで使わなきゃいけないとかw
技術力が普通にあるのなら使う必要ないんだよ
261:デフォルトの名無しさん
13/03/07 18:57:29.88
>>260
ORMは好きなの使えるっていうフレームワークもある。
JPA使えるやつなら大半の人は文句ないんじゃないの
JPAデファクトスタンダードだろうし
262:デフォルトの名無しさん
13/03/07 19:04:53.41
JPAｗ
263:デフォルトの名無しさん
13/03/07 19:05:31.48
デファクトｗｗ
264:デフォルトの名無しさん
13/03/07 19:16:01.10
なに草はやしてるんだ？
JPAはJavaでは一番メジャーなORMだろう
265:デフォルトの名無しさん
13/03/07 22:06:26.45
>>260
フレームワークの実装が特定のライブラリにがっつり依存しているか交換可能なように
設計されているかの違いだろうなぁ。
そしてそれはフレームワークの開発の速さや使い勝手とのトレードオフでもある。
GrailsはHibernate似のcriteriaも提供していたりとHibernate以外に交換するのは
しんどそう。
266:デフォルトの名無しさん
13/03/08 02:05:35.35
>>260
「やっぱり」って、不自由が発生するのを否定してるやついたか？
制約する・型にはめることによるメリットが不自由というデメリットより大きいってだけだろ
267:デフォルトの名無しさん
13/03/08 02:16:55.15
「特殊なこと」ってのが曖昧だから話にならんのだよな
ビューに関してはJSP使ってるフレームワークだったら不自由もないだろ
コントローラにしたって所詮HTTPの範疇じゃたいして特殊なことなんかできんだろ？
268:デフォルトの名無しさん
13/03/08 07:21:32.53
listの中にlistが入ってて、さらにlistが入ってるような
データが受け渡しできないから糞
そんなフレームワークばっかり。フレームワーク作ってる奴は
単純なサンプル画面しか作ったことないやつばっかり。
269:デフォルトの名無しさん
13/03/08 07:45:04.59
>>268
どのフレームワークのことを言っているのか皆目不明なのでざっくりMVCを使って尋ねるけど、
「受け渡しが出来ない」ってM・V・Cのどれからどれの間で受け渡しが出来なかったのさ。
フレームワークが使えない理由としてなにか高尚なものが来るかと思いきや、いきなり脱力な
例が飛び出してぐんにゃりですよ。
270:デフォルトの名無しさん
13/03/08 08:05:17.79
どこで受け渡しできないかも知らない程度の知識なんだとわかった
271: 忍法帖【Lv=40,xxxPT】(2+0：5)
13/03/08 08:14:16.37
>>268
批判するならどのフレームワークを使ったかくらい書くべきだね
すべてのフレームワークが同じわけではない
272:デフォルトの名無しさん
13/03/08 09:52:29.11
仕事以外の時間もプログラム板に来るような勤勉でスキルも高いであろうおまえらは
不便なフレームワークでハマる必要ないんだよ
流行りに流されてるのに気づいたほうがいい
チームに新人やスキルが低い人間がたくさんいてそいつらに大部分を任せないといけないから
スパゲッティを避けるため仕方なく使ってるという話ならわかるけど
273:デフォルトの名無しさん
13/03/08 11:04:32.79
そこでPlay! Frameworkですよ
Play! は Scala が話題になっているが、Javaでもかける。
274:デフォルトの名無しさん
13/03/08 11:58:37.45
wicketってのがXML書かなくていいらしいんだけど、うらやましい。
275:デフォルトの名無しさん
13/03/08 15:19:03.90
Playは独自感が半端なく強かったり、1.0=>2.0を見る限り不安定感が否めない。
wicketは素直な設計だし、1.5=>1.6を見る限り安定していて実用的な時期に思える。
用途に合わせて様々なフレームワークを使うぐらいなら、
wicketみたいな大規模向けフレームワークをベースに、
小規模システム向けのスケルトンソース・ジェネレータでも作ったほうが良いんじゃね？
276:デフォルトの名無しさん
13/03/08 15:57:00.15
フレームワークいらんという人はORMやDIは使うのかな。
今時手組のSQLに生のJDBCとか勘弁。
277:デフォルトの名無しさん
13/03/08 16:06:37.78
ORMなんか使わないよ。パフォーマンス悪いし。
278:デフォルトの名無しさん
13/03/08 16:12:45.10
>>276
ibatisはたまに使う。
一番いらないと思うのはDIかな。
newぐらい自分でしたい。
279:デフォルトの名無しさん
13/03/08 16:24:05.63
とはいえweb.xmlにサーブレット登録した時点でサーブレットクラスのnewに関しては既に
サーブレットコンテナに委譲しているわけだからなぁ。
その先、各サーブレットクラスが必要とする依存性を自前でnewするかこれも委譲するかで
自前ファクトリをゴリゴリ書くかapplicationContext.xmlを書くかの違いが出てくる。
インスタンス生成の委譲の程度問題だと思うんだよね。個人的にはサーブレット使うことと
DIを使うことの間にはあまり断絶はない。
280:デフォルトの名無しさん
13/03/08 16:33:16.09
とくにWebアプリでORMとかアホかと思う。
Webアプリなんてサーバー集中型なのになるべく負荷を減らさないでどうする。
ORMはクラサバアプリ向けだろ。少しは考えて欲しい。
281:デフォルトの名無しさん
13/03/08 16:55:04.22
DB知らない素人が手組みしたDBスキーマとクエリ。
DB知らない素人が定義したORマッピングとそれから自動生成されたDBスキーマ。
どちらを使えと問われれば自分は絶対に後者を使う。前者は墓穴の宝庫だが後者は
一応それなりに定石を外さないスキーマやクエリを吐く。
DBの素養のある人が手組みしたDBスキーマとクエリ。
DBの素養ある人が定義したORマッピングとDBスキーマ。
どちらを使えと問われれば、まあ使い勝手次第であって基本的にはどちらでも良い。
結局スキーマもマッパーが吐くクエリも手組と大差無いものに大抵は落ち着くから。
ただし成果物のAPIレベルでの使い勝手は当然ORMを使った方が初めから機能豊富。
結局DB理解している人間が担当しているか否かが重要なのであって、その上の上物
はプロジェクト毎に好きに決めれば良い。ただし手組みさせるとそのDB理解している
人間の手作業がバカにならん。許させる範囲でORMで楽させてあげても。
282:デフォルトの名無しさん
13/03/08 16:58:19.38
そうやって、もっさりアプリ量産してくれ。
俺の超サクサクアプリが高評価なのはおまいらのおかげだ。
283:デフォルトの名無しさん
13/03/08 17:56:34.47
どうやらただの釣りだったようだな
284:デフォルトの名無しさん
13/03/08 19:25:26.20
ORMの必要性はわかるけど後でJDBCに差し替えにくい
Hibernateとかはバッドノウハウだなと思ったり。
285:デフォルトの名無しさん
13/03/08 19:39:04.75
最近のHibernateはJPA準拠してるんでしょ
JPAならそのままSQLも扱えるとおもうけど
286:デフォルトの名無しさん
13/03/08 20:00:01.24
ORMから外れたことをするにしても外れ具合の程度によってJPQLから生SQLまで
それなりに逃げ口は用意されているよね。
普通にORMを使って、困ったときにピンポイントでそういう逃げを利用するだけでも
大概のシナリオはカバーできると思う。
287:デフォルトの名無しさん
13/03/08 21:11:52.51
ORMを使うなら範囲検索にJPQL使うのは避けられないだろ。
プロトタイプだとしても主キーと全検索だけで作るわけにはいくまい。
288:デフォルトの名無しさん
13/03/08 21:29:37.43
その辺りはクライテリアとかフレームワークごとのDSLとか。
でもJPQLは良いものだ。サクッと使うのにちょうど良い。
289:デフォルトの名無しさん
13/03/09 01:00:06.57
>>281
DB知らない素人の件は俺なら前者かな。
ORMを理解してないやつが定義したものに
ORM適用するとか足かせにしかならん。
もちろんベストはそれなりにわかってるやつにDB定義をさせることだが
知らないやつが定義した場合は昔ながらのSQLで対応する他ないと思う。
290:デフォルトの名無しさん
13/03/09 01:03:09.87
>>282
俺もフレームワークとかDIとかORMとか否定派なので主張には賛成なのだけど
スマホアプリでもないただのWebアプリで
評価が高いとか低いとかどうやってわかるの？
291:デフォルトの名無しさん
13/03/09 01:29:45.60
DIを使うのって、短期的に楽をしたりするためより、変更に耐えやすいように作るためだと思うけど・・・・
(これも、スパゲッティなコードをメンテするより、長期的に楽になる)
Springスレだったかにも書いたけど、最初は Dao の実装を1つしか作らなかったけど
(Implが１つしかないのに、わざわざインターフェースを作っていた)、
途中で、一部のテーブルだけKVSに移行したので、MyBatisImplから別のDaoImplを作って移行した。
このとき、Daoのメソッドのインターフェースを変えないようにできたので、
修正はapplicationContext.xml だけ。コントローラやサービスクラスは変更無しで済んだ。
あとUT時は、サービスクラスにDaoをDIするときにモックにするとか。
こういうことを経験すると、よほど小さかったり使い捨て以外では、DIを使った方がいいと思っている。
DIをつかうための面倒なコストは、2回ぐらい変更があったら、回収できていると思う。
292:デフォルトの名無しさん
13/03/09 01:49:16.30
JavaEEが複雑すぎたために、DIが生まれたという解説をある本で読んだ。
293:デフォルトの名無しさん
13/03/09 03:27:23.17
>>291
レイヤごとにインターフェイス統一するのは
それなりのエンジニアなら誰でもやるし
そのケースでDIコンテナを使う必然性は感じられないが…
294:デフォルトの名無しさん
13/03/09 06:22:09.43
こまめにインターフェイスを定義することとDIコンテナを使うことは別に考えるべきだと思う。
インターフェイスを定義して抽象度を上げると実装の差し替えなど融通が効くのは別にDIを
使わずとも得られる恩恵だし、DIコンテナを使うにしても別にインターフェイスの定義は
必須ではない。注入される口の型が実クラス名で決め打ちでもDIコンテナは使える。
それならDIコンテナの利点は一体なにかというと、う〜ん、DIコンテナを使っているフレーム
ワークを使うときは自分もDIコンテナを使った方が楽という点が正直一番でかいかなw
例えばSpringを使ったフレームワークを使うときは基本的にコンポーネントもDI前提で開発
するのが殆ど作法になっている。コンポーネントはDIコンテナのコンテキストに登録すること
でアプリ上にデプロイするという手順が大抵のフレームワークでほぼ共通なので、DI使えば
どのフレームワークでも簡単に似た手順でデプロイ出来るのに対して他の方法だと途端に
苦労することになる。
295:デフォルトの名無しさん
13/03/09 06:38:14.57
DIコンテナの作者が後年DIコンテナはいらないと言ってた件
296:デフォルトの名無しさん
13/03/09 10:57:51.80
当人がいらんと思ってても他の人が必要なら別にいいんじゃないの
297:デフォルトの名無しさん
13/03/09 11:04:21.79
>>296
いらないと思ってるやつが
いると思ってるリーダーの下についたときは悲惨だぞ←俺の今の状況
だからもっといらない流れができてほしいわ
298:デフォルトの名無しさん
13/03/09 11:13:19.54
>>295
ひがやすお？
299:デフォルトの名無しさん
13/03/09 12:11:10.88
>>298
YES
テストがしやすければDIコンテナは必要ないってSlim3の時に
300:デフォルトの名無しさん
13/03/09 15:35:31.76
DIの目的はテストじゃないと思うけどな。
301:デフォルトの名無しさん
13/03/09 15:50:02.45
ソースコード資産を別のフレームワークにそのまま移行する例って実は少ないだろ
302:デフォルトの名無しさん
13/03/09 16:34:51.64
wicket は Play! と同じくらい独自色がある気がする。 Play! で Java の時は、 DB のテーブル定義は ebean で、sql は 生 sql がいい気がする。
303:デフォルトの名無しさん
13/03/09 16:39:17.86
iBATISがやはり最強だな。
今まで使わないで来て今じゃMyBatisになってるようだがやはり最強。
304:デフォルトの名無しさん
13/03/09 16:42:53.41
HibernateやJPA実装の類がダメな理由はなんだろう?
305:デフォルトの名無しさん
13/03/09 16:54:23.60
RDBMSとの対応を把握する必要があるなら
最初からSQLに書けばいいじゃない。
306:デフォルトの名無しさん
13/03/09 17:07:23.68
Entityオブジェクトのクラスが決まっているのならそちらに必要最小限の
マッピング情報を書き足せば良いじゃない。
変なスキーマ相手だと苦労するけどJPA。
307:デフォルトの名無しさん
13/03/09 18:17:55.52
>>301
少ないっていうかほとんどない
著作権が客に移るからそのまま再利用できないし
308:デフォルトの名無しさん
13/03/09 18:45:15.19
>>300
DIの目的はオブジェクト(コンポーネント)を疎結合にすること、
DIコンテナによってそれが交換しやすくなる、
それが最大のメリットになるのが単体テスト。
だが単体テスト以外じゃ交換性は実は必要ない、
だったらテストがしやすけりゃDIコンテナはいらん、と読んだ。
309:デフォルトの名無しさん
13/03/09 18:52:55.16
「DBスキーマが何も無い状態から」素直なスキーマを使う小規模Webアプリをサクッと開発する
のであればMyBatisでも生JDBCでもなくJPA系が一番楽だと思う。要するにアノテーションからの
スキーマの自動生成で事足りる範囲であればこれが一番コード量が少ない。
開発序盤はデフォルトのマッピングでORMにどんどん生成させて、ある程度エンティティクラスが
出そろったり怪しげなスキーマ吐くようになった時点で一旦止めてマッピングに手を入れる。
そっから先の苦労は、結局扱うドメインモデルの複雑さそのものなのでどのフレームワーク使っても
あまり大差はないようにも思う。
310:デフォルトの名無しさん
13/03/09 19:08:28.23
>>304
JPA1.0の頃だが、一覧とかエンティティ以外の形で取るのが絶望的にダメだったところ
今はどうよ？
311:デフォルトの名無しさん
13/03/09 20:42:00.68
>>310
1.0にも、それ以前のHibernateにも、一覧結果をEntity以外の形（普通のBeanやMap）で取得する方法はあったぞ
JPQL使う必要があったけど
どうしてもSQLで書かなければいけない場合でも、HibernateネイティヴのAPI使えば普通にEntity以外の形で取れていたし
その手法を実際に適用して開発したこともある
312:デフォルトの名無しさん
13/03/09 20:56:08.16
>>311
HibernateにResultTransformerがあるのは知ってるが、それは標準じゃない
JPA標準でできるのは、
・JPQLでnew Xxx(a, b, c, ...)
・SQLで@SqlResultSetMapping(columns={@ColumnResult(name="a")}, ...})
しか知らん
前者はJPQLってところが×。関連のマッピングがないと結合もできない。Mapが使えないのも×
後者は面倒なので×。結果がObject[]なのも×
間違ってたりJPA2.0で改善されてるところがあれば教えて欲しい
313:デフォルトの名無しさん
13/03/10 21:32:05.66
ほんのちょっと前にJPA推しレスしてるやつ数人いるのに、
具体的な話になったらレス付かないとかwww
314:デフォルトの名無しさん
13/03/11 21:11:59.19
軽く調べた
・JPA2.0のJPQLではFUNC("関数名",...)でネイティブSQLの関数が使えるようになった
JPQLに無い関数も使えるのでカバーできる範囲が広がるが、
RDBに依存するならわざわざJPQL使わねーだろw
・HibernateのJPQLで複数引数のnew Xxx(a, b, c,...)は去年の夏(4.1.5)まで使えなかったw
これ誰も使ってねーだろw
・EclipseLinkは@QueryHint(name=QueryHints.RESULT_TYPE, value=ResultType.Map)でObject[]の代わりにMapになる
結局非標準w
集計的な一覧が多い日本の業務系では使い物にならんぞJPA
315:デフォルトの名無しさん
13/03/11 21:24:30.49
>>311 >>314
「一覧」という言葉を多用してるけど何のこと？
多数のテーブルをJOINするようなクエリを意味してる？
一覧とは何を指しているのかわからなかったからレスのつけようがなかった。
業務系では使えないという主張もよくわからない
JPAに限らず、ORMはマッピングさえ終えてしまえば使えるでしょう
316:デフォルトの名無しさん
13/03/11 21:52:26.07
JPAが良いって言っている人達は、どんな用途にでもJPA最高って主張しているのか？
JPAで簡単に出来る範囲のことをやる分には、JPA最高っていう主張なのかと思っていたけど。
317:デフォルトの名無しさん
13/03/11 21:56:14.85
>>315
>>310に書いただろ、「エンティティ以外の形で取る」って
>>311には伝わってたぞ
例えばMAXとかAVGとか集計関数使って部署別、期間別などの一覧を出すケース
当然、SELECT句の並びは元になったテーブル(エンティティ)とはまるで異なる
単純だがSELECT COUNT(*), AVG(a), MAX(a), MIN(a), AVG(b), MAX(b), MIN(b), ...
が必要な時、JPAではどうする？(その答えが>>312と>>314だ)
>>316
じゃあJPAで簡単にできる範囲を示さないとな。どんだけ狭いか見物だわ
318:デフォルトの名無しさん
13/03/11 22:13:39.98
>>316
>>286は「それなりに逃げ口は用意されている」から「大概のシナリオはカバーできる」
と主張してるな。「大概のシナリオ」だ、意味はわかるよな？
319:デフォルトの名無しさん
13/03/12 00:11:12.75
>>314
> ・HibernateのJPQLで複数引数のnew Xxx(a, b, c,...)は去年の夏(4.1.5)まで使えなかったw
いやそれは無いはず。JPA1.0の時代にHibernate実装でそれを使っていたから
JPAを使ったことのある身から言うと、SQLの直接記述が要件として必須なら、標準には拘らない方がいいと思う
また、JPQLをまったく使う気が無いのなら最初から止めておいた方がいい
JPA標準のNativeQuery関連は本当に使い物にならないし、SQL記述がほとんどならMyBatisで十分だろう
今はJavaの仕事していないので、最近のことについてはわからない
320:デフォルトの名無しさん
13/03/12 00:29:13.67
JPA とか吐き出されるSQLが微妙なときがあるから、変なSQL吐いてたら普通のSQLにするとか、速度的に気にしなくて良いならJPAで通すとか。各DBの方言を吸収してくれるのは便利だと思う。
321:デフォルトの名無しさん
13/03/12 01:55:03.35
hibernateから10年以上経ってて
いまだにこんなややこしい議論が必要なら
もうSQL書いたほうが早いってことだろ
322:デフォルトの名無しさん
13/03/12 09:13:52.20
でもこの差は何なんだろうね。
URLﾘﾝｸ(www.google.co.jp)
URLﾘﾝｸ(www.google.co.jp)
日本ではHibernateを使いにくい特殊事情でもあるのかな。
こんなのも。
URLﾘﾝｸ(www.google.co.jp)
URLﾘﾝｸ(www.google.co.jp)
323:デフォルトの名無しさん
13/03/12 09:42:51.79
俺の考えを述べさせてもらうと
O/Rマッピングだけでも生SQLと速度差がほとんどなくなるか
そもそもオブジェクトをそのまま扱えるDBが一般的になるまで
生SQLのほうがいいと思う。
324:デフォルトの名無しさん
13/03/12 21:47:36.02
>>319
Hibernate3.6以降の話かな
URLﾘﾝｸ(hibernate.onjira.com)
SSHから使ってた連中は別として、今JPA使うとしたらGlassFish(EclipseLink)が多いだろ
「Hibernateならできるし(震え声)」じゃダメなんだよ
あえて標準技術を選ぶ意味がない
俺はJPA(JavaEE)への移行を却下したんで「止めておいた方がいい 」のは最初からわかってる
そんなのよりJPA推し連中からのポジティブな反論を期待してたんだがな
325:デフォルトの名無しさん
13/03/12 23:22:04.17
余談だけど、JPAと言いつつHibernate前提の話をしたり、JAX-RSと言いつつ特定実装系前提の話をするJava EE推称派は、そこんとこキッチリしてくれ。
326:デフォルトの名無しさん
13/03/12 23:34:07.08
MyBatis触ってみたがこれで十分だわ
EJBに組み込む方法も割と簡単だし
327:デフォルトの名無しさん
13/03/13 00:27:43.05
>>325
標準ですむ範囲の要件であれば標準ですませた方がよい、それだけの話では？
328:デフォルトの名無しさん
13/03/13 01:04:42.17
>>327
文盲乙
329:デフォルトの名無しさん
13/03/13 01:10:39.93
hibernateって昔、1000件DELETEするときに
1000回DELETE文が走るとかでこれは使えないと断念したことがあるのだけど
いまのhibernateとかJPAとやらはそのへんは改良されてるの？
330:デフォルトの名無しさん
13/03/13 01:13:34.55
横断的な処理をする場合はJPQLを使って処理するんだろ
JPAはSELECTがJava側から見て綺麗になるくらいで後は方言吸収くらいが利点か
331:デフォルトの名無しさん
13/03/13 11:42:57.54
Linuxサーバーって一回設定したら以後放置だよね。Windows Update + Windows Serverの方がよいよね
ｽﾚﾘﾝｸ(poverty板)
332:デフォルトの名無しさん
13/03/13 15:53:58.68
>>329
調査不足つか調査力不足
Hibernate2.xの頃ですらできてた
333:デフォルトの名無しさん
13/03/13 16:53:32.09
>>332
昔って書いたのに何でそういう否定の仕方するんかね。
俺が見たのは2003年ごろだよ。バージョンは忘れた。
334:デフォルトの名無しさん
13/03/13 17:18:16.36
別に1000回DELETEすることは問題じゃないと思う。
それが1回のSQLでDELETEするのと同じ速度なら。
でもまだそういう時代じゃないからO/Rマッピングは悪だと思う。
335:デフォルトの名無しさん
13/03/13 18:07:27.21
>>333
事実だから
2002年1月リリースの0.9.2からできてたことに気づけず断念とか調査力不足だろ
336:デフォルトの名無しさん
13/03/13 18:34:57.15
>>335
まさかHQLのことじゃないよね？
337:デフォルトの名無しさん
13/03/13 18:50:25.71
すり替えｷﾀwww
少なくとも10年選手なんだろ？情けねぇ・・・
「hibernateって昔、1000件DELETEするときに」
「hibernateって昔、1000件DELETEするときに」
「hibernateって昔、1000件DELETEするときに」
どう見てもHQL使うべき場面です
338:デフォルトの名無しさん
13/03/13 19:00:25.43
できるできるってHQLのことかよ
HQL書かないといかんのなら使わんよそんなもん
隠蔽されて実行されるSQLを最適化してくれるよう
進化してるかが質問の意図だったんだが
339:デフォルトの名無しさん
13/03/13 19:09:20.82
>>338
だよな
それをわかってないんだよ
ここの奴らは
340:デフォルトの名無しさん
13/03/13 19:11:33.54
は？その意図が「1000件DELETEするときに」で伝わると思ってんの？
少なくとも10年選手なんだろ？大丈夫かお前
ついでに言っておくと、2002年の1.1からバッチ更新使うから
「1000回DELETE文が走る」も成立しない
だいたいHQL書かないならDELETE関係なくHibernate使えないじゃねーか
1000件フェッチしてくるのだって大概HQL書くだろ
idとナビゲーションだけでやるつもり？アフォですか
「10年前は未熟でした」で終わらせておけばいいものを「今も」バカだって晒してどうする
341:デフォルトの名無しさん
13/03/13 19:14:31.73
ファビョるなw
342:デフォルトの名無しさん
13/03/13 19:16:26.44
一応書いておくが、俺(340他)はHibernate使えるとは思ってない
↓がバカだと思っただけだ
> 1000件DELETEするときに
> 1000回DELETE文が走るとかでこれは使えないと断念
343:デフォルトの名無しさん
13/03/13 19:16:53.38
そもそもオブジェクトを操作するだけでSQLと遜色ない速度で
動いてくれないと意味ないんだよ。
344:デフォルトの名無しさん
13/03/15 01:16:45.46
亀レス＆スレチですまん。
>>224
いまだにメインはJavaなんだけど、node.jsを使い始めてる。
フロント側をJavaScript+jQueryでやることが多くなって
サーバ側も同じ言語が使えるのは良い感じ。
ただ、JSはタイプセーフじゃないから、巨大なシステムにはまだ不安。
345:デフォルトの名無しさん
13/03/15 14:12:49.96
タイプセーフは重要
346:デフォルトの名無しさん
13/03/16 00:31:32.17
>>344-345
同じ言語を使えるってのは楽でいいね
言語の問題は置いておいて、node用のフレームワークの出来はどう？
expressだっけ？
TypeScript使えばJSも部分的にTypeSafeになるんじゃない？
347:デフォルトの名無しさん
13/03/16 00:47:09.87
Expressが必要なところでNode.jsを使ったら負けだと思ってる
348:224
13/03/16 22:53:33.58
>>344
node.jsか。レスありがとう!
349:デフォルトの名無しさん
13/03/18 20:10:52.78
Mybatisのセカンドレベルキャッシュってどこに保存されてるんだろ
Serializableを要求するからTEMPフォルダでも指定してるのかと思ったが見あたらない？
もしかしてインメモリなのか？ローカルキャッシュよりは全然遅いのだが
350:デフォルトの名無しさん
13/03/18 20:49:09.28
ああreadonlyに設定してないと読み取りの度にシリアライズが走るのか
イミュータブルにすると周囲にやや不評だろうけど安全だしそうするか
351:デフォルトの名無しさん
13/03/20 00:08:40.52
mapper XMLでinsertをする時、useGeneratedKeysを指定すれば自動採番されたIDが取得できるのは
わかってるんだけど、これって単発insertのときだけじゃないですか。
insert selectで複数行をinsertしたとき、全部の自動採番IDを取ることって出来るんですか？
352:デフォルトの名無しさん
13/03/20 01:00:57.18
生JDBCのgetGeneratedKeys()はResultSetを返すんだからできるんじゃねーの？
353:351
13/03/20 01:13:31.36
いろいろ端折り過ぎてた
spring + myBatisでPostgreSQLです
keyPropertyに指定するフィールドを配列やListにしてみたんだけどダメだったなー
生JDBCでできているてことは、自前でhandlerとか作ってやればいいのかな
354:デフォルトの名無しさん
13/03/25 11:00:30.07
O/R マッピングは便利なんだけど何を使ってもテーブル結合と集計で悩む.
Entityと1:1にならない1000SQLのために対応するDTOを1000作るのか？ みたいな.
型の安全性とか名前の管理とか考えたらList<Map>よりずっとマシなんだけど数がなぁ…
355:デフォルトの名無しさん
13/03/25 11:10:09.19
あと、Tableに対応するクラスはEntityでいいとして、SQLに対応するクラスは何と定義してどのパッケージに突っ込んでる？
前者をDomainEntity, 後者をCustomizeEntityと呼んで同じパッケージに突っ込んでるプロダクトもあるみたいだけど.
356:デフォルトの名無しさん
13/03/25 11:31:00.42
だからまったくSQLを意識しなくてすむレベルまでオブジェクトにしても
パフォーマンスがぜんぜん問題にならないくらいになるまで
使うべきじゃない。時期尚早。
357:デフォルトの名無しさん
13/03/25 11:52:33.44
>>356
使わないのも選択肢としてありだと思うけど>>354-355の課題は使用有無に関わらず発生するよね
これみんなどうしてるのかねぇ
358:デフォルトの名無しさん
13/03/25 12:15:04.22
>>354
適材適所でいいんじゃないの
SQL使うほうが楽な場所はSQLで直接やればいい。
お決まりの処理で性能を満たす場合はORMで。
359:デフォルトの名無しさん
13/03/25 14:06:30.14
>>358
まったくそのとおりだと思う。
実際ORマッパには生SQLを発行できるタイプもあるし、
生SQLで検索したものをオブジェクトにマップもできる。
(マップできないようにもできる。集計やグループ化もたいていは対応してるんじゃないかな。)
SQLインジェクションにならないようにするだけでも価値があるし、
コネクションプーリングだけでも有用だと思う。
ORマッパにもよると思うがあまり毛嫌いする要素はないと思う。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
4389日前に更新/201 KB
担当:undef