ドメインモデル VS トランザクションスクリプト
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2009/05/03(日) 18:02:12ID:vXt2lE+8SQLがわんさか書かれた後に、DBの変更が頻繁に行われるので、生産性が著しく下がる。
PofEAAで解説されているドメインモデルでどうして実装しないんだろう？
俺が身近な人に聞いた理由：
１．難解なモデリングをするイメージがあるから（アナリシスパターンのせいか？）
２．どうすれば実現できるかわからないから（アーキテクチャが複雑になるから？）
３．業務アプリにドメインモデルは向かないから（イベントドリブンではないから？）
４．Hibernate(EJB3)が重厚すぎてトラブルが起きたときに怖いから（フレームワークのノウハウがないから？）
５．画面毎に実装させないと作れないから（開発者がへぼいから？）
俺はHibernateを使わずにDAO＋リッチなORマッピング処理を自動生成する方法
（Ruby On RailsのActiveRecordみたいなかんじかな）で開発するのが好きで、
それを使ったプロジェクトでは実際に、生産性も保守性も高いと思うんだけど。。
どう思う？
010391
2010/03/22(月) 09:52:14ID:???相手も同じペースで書いたらどうなるかを想像してほしい
技術者とはコードを書くだけが仕事ではないはず
特にアーキテクトなどのように上流工程にいくほど、コード以外の割合は増えていく
コードに対する美意識をほんの少しでもいいから普段の文章にも向けてみて欲しい
そして、>>77がこれまでに書いたコメントをアーキテクト的な視点で見直してみてほしい
これも「技術者としての自負を持つ」ために必要なことだろう
もちろんこれは自分にもいえることで、酷い文章だったと思う
それでも、論点を絞り、宗教論争にならないように気を付け、そして収束に向かうように
できるだけ努力したつもりだけどね
>>102
>実際オフ会とかでコードをもとに話してみたいですね。
>そうするともっと建設的な議論になるのかな。
この手の議論はかならず宗教論争になり、そして崩壊する
なぜなら君のような信奉者が現れるから
争いを煽り、特定の考えを絶対視し、相手の意見には耳を貸さず、相手を蔑む
君のコメントを読んでオフ会を開きたいと思う人はおそらく存在しないが、
ブログ等で発表することはできるし、必要ならここで宣伝すればいい
0104nobodyさん
2010/03/22(月) 11:02:46ID:???0105nobodyさん
2010/03/22(月) 11:29:36ID:???0106nobodyさん
2010/03/22(月) 12:11:08ID:???そこで是非素晴らしい意見の数々を疲労してほしいな☆
てゆーか、どこかの会場を借りきって説明会開いて欲しい☆
0107nobodyさん
2010/03/22(月) 12:12:05ID:???疲労→披露
でした☆
010891
2010/03/22(月) 13:30:18ID:???これの問題点だけ書かせてもらう
・「注文の登録」という具体的な例に、hoge, foo, model, otherEntityのような
意味のない名前が使われている
（特にotherEntityが何を想定しているのか分からない）
・「foo, bar」と「hoge, piyo」を混在させている
・ドメインモデルを説明するためにはドメイン層こそ例示すべき
・ドメインモデルの力を示すためには、ある程度複雑なドメインを扱う必要があるが
この例はスペースを考慮しても簡単すぎる
・サービス層のメソッド名として「persist」と「merge」は相応しくない
「register」等の名称（そして内容）にすべき
・アプリケーション層で行っている条件分岐は、サービス層の「register」内で行うべき
・「calculate」はおそらく「xxxOtherEntity」内で行うべき
（仕様上そうしてはいけない特別な理由があるのなら、その理由を明記すべき）
（また、特殊な場合であれば例として用いるべきではない）
重箱の隅をつついた嫌いはあるが、>>82のような極めて単純で小さなコード例にこれだけの
問題があることは珍しい。美意識が聞いて呆れる
あともう一つ、ひがさんの考えを「全面的に支持している」と書いたのはまずかった
あくまでも「シンドメインモデル」という考え方を支持しているということで、
ひがさん自身やSeasar2やS2Dao等の特定のプロダクトまで無条件で支持しているわけではない
また、Hibernateや「（リッチ）ドメインモデル」を否定しているわけでもない
※念のため、これらについて君と議論するつもりはない
010999
2010/03/22(月) 16:39:29ID:???「トランザクションスクリプトを使う人は技術力が低い」という主張が
「複雑な業務ならドメインモデルを使えばいい」に変わったのなら
フレームのもとをなくしたという意味では事態は好転してるんじゃないかな。
話を帳票に戻して、どういう「複雑な業務」なら、
「管理帳票」をドメインモデルで適切に扱えるのだろうか。
>>56を読むと「一次キャッシュ」が決め手になるようだけど。
ちなみに俺は>>97に挙がっている本を教科書だと思っていないし、
オフ会に参加するつもりも無いので、それを理由に発言ごと無視してくれても良いよ。
011091
2010/03/22(月) 19:19:27ID:???見落としていたことがあるので>>108に追記させてほしい
>>82の例における>>89のポイントについて
そもそもDAOとはデータベースへのアクセスをカプセル化するものであり、
例えばHibernate用DAOからiBatis用DAOに交換したとしても理論上は全く同じように
動作するように設計すべきもの
（そもそもHibernateにDAOは馴染まないという意見もあるが）
>>89はそれを満たしていないばかりか、高度なO/Rマッパー特有の機能をDAOに
持たせたことを、素晴らしいことのように吹聴してしまっている
これではDAOを使うメリットが無いばかりか、手間が増し、混乱を引き起こすだけ
この例においてはDAOを使うのは明らかな誤り
011177
2010/03/23(火) 01:13:55ID:/q+wWJE0レスありがとう。明日から会社ですよ。
>重箱の隅をつついた嫌いはあるが、>>82のような極めて単純で小さなコード例にこれだけの
>問題があることは珍しい。美意識が聞いて呆れる
そういう所を見てたんですが・・・。
個人的には名称うんぬんはどうでも良くて考えてましたよ、少なくとも今は。
ごめんなさい。
↓のようなツッコミを想定してました。
で、これについて議論したかった。
>・アプリケーション層で行っている条件分岐は、サービス層の「register」内で行うべき
>・「calculate」はおそらく「xxxOtherEntity」内で行うべき
また、このコードをS2Daoで書いたらmergeの所に配管コードが量産されることを
このレスを見ている人に分かって欲しかった。そこを分かってくれる人と議論したいとも思ってた。
>あともう一つ、ひがさんの考えを「全面的に支持している」と書いたのはまずかった
>あくまでも「シンドメインモデル」という考え方を支持しているということで
できれば、91さんの考えを知りたいな。
「ER中心に考えてなぜドメインモデルが成立するのか」って結構証明が難しい問題だと思う。
シンドメインモデルっていうかリッチトランザクションスクリプトでしょう、と思う訳で。
まあ、用語はともかく、実際に複雑な業務をシンドメインモデルで表現した場合に発生する配管コードの量&重複コードの量と
(リッチドメインモデルを採用するのに比べて)実装・設計の簡単さという所のトレードオフなんかは自分も常々悩む所。
011277
2010/03/23(火) 01:28:08ID:/q+wWJE0>>>103を書いてしまった手前、非常に心苦しいのだけど
>見落としていたことがあるので>>108に追記させてほしい
気楽にやってください。自分は基本的には何も気にしてないんで。
>>>89はそれを満たしていないばかりか、高度なO/Rマッパー特有の機能をDAOに
>持たせたことを、素晴らしいことのように吹聴してしまっている
>これではDAOを使うメリットが無いばかりか、手間が増し、混乱を引き起こすだけ
>この例においてはDAOを使うのは明らかな誤り
そう。そこ。そういう指摘が欲しいんですよ。
ドメインにロジック書くだけでワークできる程度の複雑さの業務だと、
hibernateでDaoがいらないケースが多い。
けど、サービスにどうしてもロジックを書かなくちゃいけないレベルの複雑さになると
Daoでクエリをカプセル化したくなるんですよ。ロジックと配管コードが混在して汚いから。
自分はそういう問題点が気になって仕方ないので、お客様には非常に申し訳ないけど
こっそりとDaoを使う場合、使わない場合で実験してたわけ、で結論としてはやっぱり
Daoを作った方が無難だということ。
なぜなら、後から想定以上に業務が複雑な事が分かってDaoが欲しくなったとき
リファクタリングするのが面倒だから、安全策で。ということなんですよ。
こういうのって、どういう風に考えてました？
011377
2010/03/23(火) 01:55:24ID:/q+wWJE0>「トランザクションスクリプトを使う人は技術力が低い」という主張が
>「複雑な業務ならドメインモデルを使えばいい」に変わったのなら
>フレームのもとをなくしたという意味では事態は好転してるんじゃないかな。
ぶっちゃけ 「トランザクションスクリプトを使う人は技術力が低い」なんて一度も言ってないんですけどね・・・。
「hibernateでトランザクションスクリプトする奴はアホすぎる(その逆もそう)」とかは何回も言いましたが。
言い方が悪かったんでしょう。ごめんなさい。
>話を帳票に戻して、どういう「複雑な業務」なら、
>「管理帳票」をドメインモデルで適切に扱えるのだろうか。
>>>56を読むと「一次キャッシュ」が決め手になるようだけど。
帳票と言ってもそのシステムにおける重要度でモデリングは如何様にもかわるので、
前提がないと・・・なんですが。
例えば、帳票が主体のシステムだと、それがドメインとなるわけで、そのままドメインモデルで
表したらおkですよね。簡単な話。
問題は帳票が付属品みたいなやつ。
しかもメインのビジネスフローと異なった体系だったりする場合。
このときメインのビジネスフローをドメインモデルで表現すると、
明らかに確実に帳票はミスマッッチしまくりで破綻する。
で、こっから先は長くなるのですが、そもそもこういう回答の雰囲気で質問の意図満たしてます？
1次キャッシュとかいってるので外してたら怖くて。
>ちなみに俺は>>97に挙がっている本を教科書だと思っていないし、
>オフ会に参加するつもりも無いので、それを理由に発言ごと無視してくれても良いよ。
じゃあ何で、ドメインモデルって単語知ってんのよ！と強く思いますが、まあ、それはどうでもいいです。
99さんの教科書を是非示して欲しい。自分で言うのもなんだけど、ある程度の読書はしているので
よほどトリッキーなものでない限り大抵知ってるつもり。背景がわかると話が簡単になる場合が多いので。
011477
2010/03/23(火) 02:18:23ID:/q+wWJE0>コードなら説明できるというわりに、やたら「人」にこだわるんだな
この手の議論て宗教論争になるのが常じゃないですが、
けど、コードレビューをもとに議論すると実はそんなに激しくならないんですよ。
もちろん「JavaでOOでシステムを作りたい」という前提の人との議論に限るのですが。
「Javaで構造化設計やりたい」という人とはやはり宗教論争になりますが。
ちなみに「トランザクションスクリプト= 構造化設計」ではないですから。誤認しやすいけど。
自分の理解だと、JavaでOOやりたい人はすべからくドメインモデル派なんだけど、
様々な事情で仕方なくトランザクションスクリプトやってる、と思ってるので。
>>105
>現実の人に相手されないからここで吠えてんだろうなｗ
逆かなあ・・・現実はある程度落としどころが見つかったんで、
ネットの皆様はどう考えてんだろうと思った次第。
>>106
>Hibernateの人（仮称）には是非ブログを解説して欲しい。
>そこで是非素晴らしい意見の数々を疲労してほしいな☆
>てゆーか、どこかの会場を借りきって説明会開いて欲しい☆
説明会の類いは仕事でずっとやってるので、一緒のプロジェクトになれたら是非w
ただ、自分が常にhibefnateを使うかというとそうでもないので注意が必要なのですが。
自分がアーキやってるときは、S2Dao 2: iBatis 2: hibernate: 3 RoR: 1くらいかな・・。
レガシーな時代を入れると↑は全然違うけど、直近だとこんな感じかな。iBatisも以外に多いですよ。
DIコンテナをspringにしてからはS2Daoは使ってないですね。当たり前だけど。
最近はJavaはおなかいっぱいでRoRに走ってるけど。
ブログはめんどくさいんですよね・・・。
ちょっとやってみようかなあ。
011577
2010/03/23(火) 02:25:36ID:/q+wWJE0×
S2Dao 2: iBatis 2: hibernate: 3 RoR: 1くらいかな・・。
○
S2Dao 2: iBatis 2 springJDBC: 2: hibernate: 3 RoR: 1くらいかな・・。
でしたw
011699
2010/03/23(火) 03:28:36ID:???> そもそもこういう回答の雰囲気で質問の意図満たしてます？
満たしてます。それが話の本筋だったはず。
>>56-57あたりからぐだぐだになって話が逸れまくったのでは。
こちらの背景は畑違いなのでどうぞお気になさらず。
>>52の問題提起に対する>>54の回答内容に疑問があって質問しただけです。
0117nobodyさん
2010/03/23(火) 04:02:05ID:/q+wWJE0>満たしてます。それが話の本筋だったはず。
帳票が付属品の場合ですよね？
帳票が定時出力なのかオンデマンド出力なのかで変わりますが、
定時出力の場合:
帳票用のドメインモデルを作って、バッチかなんかで主要ドメインから帳票用のドメインに詰め替え&ロジック&永続化する。
で、帳票出力するときは、その永続化した帳票用ドメインモデルをそのまま出せばいい。
つまり、ドメインモデルが２つ存在するパターンです。
(ちなみに、帳票のロジックが全然たいした事ない場合はトランザクションスクリプトでもおkです。
実際はこっちのケースのが多いでしょう。)
オンデマンドの場合:
定時出力と同じでもいいんですが、設計上それが厳しい場合、
(テーブル作るのがいろんな理由でヤダとか、帳票出力アクション毎になんらかの処理をかませる必要があるとか)
帳票用のドメインモデル構築は諦めて、
DFDっぽく、inが主要ドメイン -> 変換ロジック -> out帳票用DTO(not ドメインモデル)しかない。
けど、これじゃ"変換ロジック"の所が手続き型のコードで汚くなるので、
そこをFWを使って美しくできるよう努力したほうがいい、
と言ってました。
ただ、これって正直ドメインモデルうんぬんというよりも、そもそもの設計の話だし、
1次キャッシュは全然絡まないわけですが、こういうことを質問してたんですよね。
>>>56-57あたりからぐだぐだになって話が逸れまくったのでは。
すいません。
ただ、ドメインモデル Vs トランザクションスクリプトを思想レベルから実装レベルまで議論しようとすると
どうしてもhibernateは避けて通れないと自分は考えてて、まずはこのスレにいる人がどういう人なんだろうと
思ってて。あんな感じにw。まあ、もうどうでもいいですが。
0119118
2010/03/25(木) 23:05:51ID:???0120nobodyさん
2010/03/26(金) 00:51:52ID:???複雑なキャッシュ(依存関係や階層ね)をモデリングしたい、って感じ。
DataStore 頻繁に叩いたり、デカいFramework起動すると
金かかるんだよね。
開発期間も短かくしたいから、うすいドメインモデルでいい。
0122nobodyさん
2010/05/24(月) 19:40:41ID:???ttp://togetter.com/li/10063
0123nobodyさん
2010/05/24(月) 20:38:23ID:???0124nobodyさん
2010/05/25(火) 21:16:56ID:???エンジニアライフの記事をいくつか読んだけど生島勘富がひどすぎるｗ
社長で実名なのに読解力無さすぎ、カス・クズって言い過ぎｗ
77と被るけど結論は真逆なのがまた面白い
もしもまだ居たら77の感想が聞いてみたい
0125nobodyさん
2010/06/19(土) 18:18:16ID:???オブジェクトを永続化するときにオブジェクトのまま扱えるのか、
パーシスタント層を意識してデータに変換してあげなきゃいけないのか、
がフルスタックORMとなんちゃってORMの違いなのに、ドメインモデルか
トランザクションスクリプトかは関係ない。
自システムでDBを扱わず永続化を外部システムに丸投げしてHibernateもiBatisも
使わない場合だって、ドメインモデルでもトランザクションスクリプトでもどっちでも書ける。
これにS2Daoをなんちゃってと言われたことを面白くないと思った人が
過剰反応してこじれてしまったのだろうか。
>>122に関連して
SQLにドメインロジック入れるのは2層時代の作り方だよ。パフォーマンスは
一番出るけど拡張性、メンテナンス性を考慮しつつコードを自動生成して
巨大なシステムを短納期で作って、ボトルネックになるところだけ改善するっていう
今のやり方とは合わない。
0126nobodyさん
2010/06/21(月) 00:16:57ID:???0127nobodyさん
2010/06/22(火) 02:19:15ID:???>パーシスタント層を意識してデータに変換してあげなきゃいけないのか、
>がフルスタックORMとなんちゃってORMの違いなのに、ドメインモデルか
なんだこのオレオレ定義ｗ
しかもデータに変換って…
0128nobodyさん
2010/12/06(月) 21:56:20ID:???復活しる！
0129nobodyさん
2010/12/06(月) 23:30:49ID:???エンタープライズ系は、もう過去の世界の話なので、どうでも良い気がする
今は、クラウド系のアーキテクチャデザインの方が知りたいわ
0130nobodyさん
2010/12/07(火) 00:43:44ID:???的はずれにも程がある
0131nobodyさん
2010/12/07(火) 15:28:29ID:???0132nobodyさん
2010/12/13(月) 23:05:53ID:???>５．画面毎に実装させないと作れないから（開発者がへぼいから？）
これ多い。画面ごとにdao作ってってパターン。
ン億かけた某社のWebシステムもこれだった。
で、顧客から「今度小さいシステムを別で用意するんだけど、
こないだの情報と組み合わせてちょろっと出したい」と言われた時に
画面特有ロジックと密結合過ぎて切り出せない。
1画面の情報 = 1テーブル。無理。yobi6とかいうカラムまである。
仕方ないから完全別でシコシコ作る。当然one fact, many placesになる。
それで解決策を探してたのがドメインモデルを知るきっかけだった。
まだ勉強中だけど。
ちなみに画面ごとに作る理由を聞いてみたら、
画面数と帳票数からクラス数とかが分かるから、
見積もりがしやすいって意見だった。
>>131
「こういう場合に」とかの具体例がないとなんともいえないのでは。
0133nobodyさん
2010/12/19(日) 22:20:36ID:???粗結合になりシンプルで好きです。
ドメインモデルはLLライクな気がする
0134nobodyさん
2010/12/20(月) 07:04:02ID:???> ドメインモデルはLLライクな気がする
何か誤解してるな
LL≒スクリプト言語
スクリプトと付く意味を考えたらこの結論は出ない
0135nobodyさん
2010/12/21(火) 04:04:06ID:???ドメインモデルは大クラス主義だという意味さ ＞LL
俺の考えとしてはエンティティは単純なVOであるべき。
ドメインオブジェクトがFacade的な役割に過ぎないならいいけど
エンティティと一体化した実装だとすれば肥大化しすぎる
0136nobodyさん
2010/12/21(火) 08:15:47ID:???ドメインモデルだから大クラス主義ということはないし（どちらかと言えばむしろ小クラス）、
大クラス主義はあくまで特定言語のライブラリの思想であって、LLとは直接の関係はない。
VO（Value Object）の意味も誤解している。（PoEAAを参照）
> ドメインオブジェクトがFacade的な役割に過ぎないならいいけど
これではドメインモデルとはいえない。
> エンティティと一体化した実装だとすれば肥大化しすぎる
適切に実装できれば、個々のクラスが肥大化することはない。システム全体で見てもトラン
ザクションスクリプトの方がコードの重複が発生しやすく、肥大化のリスクが高い。
0137nobodyさん
2010/12/22(水) 01:38:58ID:???DIとDDD相性悪いのはどうなんだろ
0138nobodyさん
2010/12/22(水) 08:07:42ID:???全くの逆で、大規模・複雑な問題こそドメインモデルが適している。
また、DIとの相性が悪いということもない。むしろドメインモデルにこそ必要。
あまりにひどいから釣りかとも思ったけど、「DIコンテナとドメインモデルの相性の悪さ」
というブログ記事を読んで納得した。たぶんこの記事を読んだんだろう。
> ドメインモデルは、非常に単純化しすぎた言い方をすれば、トランザクションスクリプトの
> EntityとLogicを1クラスにまとめたようなプログラミングモデルになる。
こんな馬鹿な設計はないしドメインモデルでも何でもない。この通りに実装したら確かに
>>135,137の通りになる。
>>11で酷評されてるが「ドメイン駆動」は良書だから読むことを薦めるよ。
0139nobodyさん
2010/12/24(金) 08:20:47ID:???0140nobodyさん
2011/01/02(日) 17:17:59ID:d+V9EiWf0141nobodyさん
2011/01/03(月) 13:58:38ID:???コードの重複を減らして変更に強くする
可読性の低い複雑なアーキテクチャ
設計：
RDBのデータ設計、パフォーマンスに難あり
開発工程が、人数増やしても効果出にくい設計フェーズに集中する
実装：
コードの量が少ない、人件費少ない。
OOP的なコード書くの嫌いor書けない人多い。
0142nobodyさん
2011/01/19(水) 23:42:55ID:???読後感としては、ドメインモデルってそこまでお堅いもんでもないのかな、と。
著者も著者の友人も、ドメインモデルをそれぞれ解釈している。
特に.NET界隈の事情の影響が非常に大きいのではないかと感じた。
MicrosoftのTier分割思想が垣間見得た。
このスレでドメインモデルを知った俺としては、ここの人の方がよっぽど純粋主義に見える。
「ドメイン駆動」がドメインモデルの体現だというのはにわかに首肯しかねるけど、
実践部分に特化した部分では意義があると感じた。
「そういう解釈もあるのか」という部分も強く感じたので、もう一度PoEAAを読み直す予定。
0143nobodyさん
2011/01/20(木) 00:06:07ID:???それにしても2005年時点で「もう古い」という意見が多々。
確かにドメインモデルを使わない案件でもRow Data Gatewayはもう一般的。
O/Rマッパーも一般的か。クラス構造とテーブル構造が一致している場合での、
効率化目的で使われていることがほとんどではあるように思うけど。
この読書会に参加した方は、今どういった方面に向かっているのだろうか。
何世代も遅れている上に、まだまだ理解の足りない自分に若干の嫌気。
0144nobodyさん
2011/01/21(金) 20:48:18ID:???ドメインモデル関連はPoEAAよりも>>40のほうが参考になると思う
ドメイン駆動を読んだら理解できるようになってるはず
0145nobodyさん
2011/01/22(土) 02:51:10ID:???0146nobodyさん
2011/01/25(火) 19:14:54ID:???0147nobodyさん
2011/01/25(火) 23:09:21ID:???O/RマッパーのないRow Data Gatewayとか死ぬほど大変そうなんだけど。
0148nobodyさん
2011/03/17(木) 12:31:23.36ID:???＞ttp://www.seshop.com/product/detail/13087/
＞
＞エリック・エヴァンスのドメイン駆動設計
0149nobodyさん
2011/04/09(土) 20:54:03.20ID:???原書も持ってるけど、理解が怪しい部分もあるし、なんだかんだで邦訳はありがたい。
今からざっと目を通すけど、糞翻訳でないことを祈るのみだわ。
0150nobodyさん
2011/04/09(土) 21:03:01.35ID:???いやー待っただけあって、なんか興奮するわ。酒も入ってるけど。
おまえらもモチベーション上がってくるよな？な？
0151nobodyさん
2011/04/11(月) 09:27:49.40ID:???0152nobodyさん
2011/05/17(火) 12:49:22.86ID:8ytboqBq>>8 で書かれている Eric Evans の Domain Driven Design の日本語訳が、
>>148 の 翔泳社の本ですよね。
>12 や >>138 で書かれている「ドメイン駆動」というのは、
http://www.seshop.com/product/detail/8906/
の本のことでしょうか?
0153nobodyさん
2011/05/23(月) 00:49:46.14ID:???0155nobodyさん
2011/10/23(日) 20:39:54.26ID:YBM1A9Aj> 「O/Rマッパー = オブジェクトクエリでCRUDできる」が正しい。
「出来る」だってｗ
hibernate案件で
副問い合わせした後でgroup byしたものをjoinする必要があったが
ヘンテコなクエリで悩まされたわ
あんな独自の馬鹿馬鹿しいクエリは二度と使いたくないね
やっぱりSQLで問い合わせるのが一番だ
0156nobodyさん
2011/10/23(日) 20:47:26.90ID:YBM1A9Aj> (つまり、UinitOfWorkをアーキテクチャの原則としている)
>
> S2Dao、iBatisにはそういう機能はない
>
> この違いを表現するのに"なんちゃってO/Rマッパー"と言っているだけ。
> ほかに良い表現方法があればそれを使うけど、特にないのでそう言っている。
遅レスだがｗ
なんだコイツ？
「一時キャッシュがあるから高機能」とか
馬鹿か？
どんだけ永続化マンセー野郎なんだ
そのキャッシュの間に、本番DBの値が変更したらどうなるか？
更新の時に不具合が出る場合もあることに頭が回らんのかねｗ
0157nobodyさん
2011/10/24(月) 22:55:11.73ID:???> そのキャッシュの間に、本番DBの値が変更したらどうなるか？
心配しなくてもそれなりのODBはキャッシュコヒーレンシープロトコルをもってる
0158nobodyさん
2011/10/24(月) 23:19:25.34ID:IvAvPYHsOracleで言うと、読み取り一貫性の機能を言いたいんだろうが
勘違いしてるな
Aが画面で編集してる間に
Bが更新処理を完了してる、というケースを考えてみろ
Aがイザ更新をしようとすれば、すでにDBの値は変更されてしまっている
そのまま更新しようとすると制約などがあればエラーになるケースもある
0159nobodyさん
2011/10/25(火) 13:53:20.00ID:ZETKDX7R0160nobodyさん
2011/10/25(火) 19:21:27.40ID:???0161nobodyさん
2011/10/25(火) 19:29:33.75ID:ZETKDX7R0162nobodyさん
2011/10/25(火) 19:34:32.27ID:???0163nobodyさん
2011/10/25(火) 19:58:22.71ID:???モデル層の話はほとんど行われない、っといういつもの光景か。
0164nobodyさん
2011/10/26(水) 00:55:43.76ID:???0165nobodyさん
2011/10/26(水) 03:17:49.96ID:yaFVf5onこれも否定できない事実だ
0166nobodyさん
2011/10/26(水) 19:32:24.27ID:???■ このスレッドは過去ログ倉庫に格納されています