引用：

「setter getter」に関しては、小生も「わけわかめ」。。。

いづれにせよ、題名から、趣旨が外れて来ましたので、
「Yellow Book for EC-CUBE」なスレッドを起こします。

> # Java 嫌いな方には顰蹙を買いそうです(汗)

変数で駆逐を目指したはずの「ラクダ」が、メソッドでやたら蘇っている！

これは地味に嫌だ。


【追記】
・・・って、おい！ 脳内 PHP コンパイラが Notice 発報。


やっぱり、(Java でありがちな) 画一的な setter getter を PHP に持ち込むのは勘弁・・・

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

> このデータ作るためにforeachが多すぎる気がしちゃいます。。

全てのエンティティクラスで同様に記述するなら、確かに多いような気はしますね。

ただ、ざっと見た印象では、ある程度は基底クラス化できそうなので、相対的な記述数は削減できるのかも。

あと、SC_Entity_OrderDetail#getCategoryIds の foreach あたりは、冗長に書いてしまったポカミスかなとも。


> update分も逆に冗長になってるような

確かにサンプルだけ見ると、そんな印象はありますね。

現実的に重要なのは、もっと実際の実装のように、込み入った時にどうなるかでしょうか。


> updateしたい値以外不要な情報ですよね

最近は、DB の処理が最適化される方向なので、この辺りの心配は軽視できそうです。

そうでなくても、エンティティクラスサイドで、差異のあるカラムのみ出力するとかは簡単にできそうな気もします。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

書き方が悪かったですね、SQLの関数を使うではなく、PHPの関数化するです
SC_DB_DBFactoryを使うイメージです

SQLも部品化して再利用しやすいようにしてやるほうがメンテも、使い回しもしやすいかなと。プラグイン化もしやすいですし

----------------
EC-CUBEのカスタマイズ、トラブル解決承ります
お気軽にお問い合わせ下さい
https://www.ec-cube.net/integrate/partner/partner.php?partner_id=690

> SQL86, SQL89, SQL92, SQL:1999, SQL:2003, SQL:2006, SQL:2008, SQL:2011
> 以降でも「関数」が「担保」されるのであれば、それは「良い」かもしれません。

個人的には、「現状使えて、(実装レベルで)廃止の方向でない」ならば、そこは「良し」かなと思います。

非対応な実装に対しては、リアルな DBMS の関数でなく、DBMS で処理させる為の仕組みでも代替可能でしょうし。


とはいえ、この処理を DB 関数で行うは、今のところ些か否定的な気分ですけど・・・

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

最後の、、、EC-CUBE、、、からの「逸脱」として。。。

引用：

SQL86, SQL89, SQL92, SQL:1999, SQL:2003, SQL:2006, SQL:2008, SQL:2011
以降でも「関数」が「担保」されるのであれば、それは「良い」かもしれません。

引用：

この辺りは「M」の作り込みに際して「思慮」が如何に深くなされているかではないでしょうか？
この辺りを、少しづつ掘り下げで行きたい思っています。

引用：

プログラム言語は、それを提唱した「人」の「その時点での信念でしかない」のですから、
javaもその「信念」を継承出来ない時期に来ており、、、プログラム言語は

引用：

において、その都度、生まれ、変化する。。。

「php」や「java」、、、「他」、、、を駆逐する「概念」が出て来てきていない今、、、
「何をどうして良いのか」、、、「頭の中」で「ホワイトペーパー」が駆動されていな状態では何も提言出来ないのですが、、、

「はやぶさ」を帰還させた JAXAの「知」も持ってすれば、雑作もないことだとは思うだが。。。

個人的には税計算もSQLでやっちゃえばいいんじゃないかと思うんですが・・
SQLを関数化してしまったほうが何かと使い勝手良くないですか？

このデータ作るためにforeachが多すぎる気がしちゃいます。。
update分も逆に冗長になってるような・・updateしたい値以外不要な情報ですよね

※java文化全く無いのでごめんなさい

----------------
EC-CUBEのカスタマイズ、トラブル解決承ります
お気軽にお問い合わせ下さい
https://www.ec-cube.net/integrate/partner/partner.php?partner_id=690

＞nanasess様
＞Ringo様

大変貴重なご意見をありがとうございました。
エンティティは使い勝手も良さそうですし、一度試してみようかと思います。

># Java 嫌いな方には顰蹙を買いそうです(汗)

これは「jaba嫌い」とは、全く関係ないんでは、ないでしょうか。。。

PHPの連想配列の次世代がエンティティ(コンストラクタ)ではないのでしょうか。。。

どっちが、新旧との議論ではないです。

人とCPUの親和性の議論です。
人とDSPの親和性の議論です。

こんにちは。。。

全くもって、ECCUBEからは逸脱しますが、、、

この直近で、Webアプリケーションシステムを構築する案件があって、、、小規模であったので、

小生の手の内、、、
PHP・Smarty
java
　jsp
　struts
　spring
　seaser2
　click(含むVelocity)
から、code and driveの効率から、clickを採用したものが有りました。

メインフレームからの移行ですと、seaser2辺りまで持っていかないと、信頼性の担保が出来ないでしょう。

>＞本当は、対象のエンティティクラスを作って、・・・

これは、nanasess様からの提言であって、
本人も曰く、結構、javaよりになってまずが、小生の様な、機械語育ちで、現状、『java』を選択し得ざえない身からみると、 『そうだよね』、、、な、『賛同できる点の多い』提言と思えます。

>この辺りの指標というか、「これが本当だ！」と言う根拠になるようなモノってあるんでしょうか。

『小生の知る範囲』では『無い』です、、、ねぇ。。。
OSSへの貢献の多い方からは『これが、今の一押し』な、主張が得られるとは、容易に、想定します。

>似たようなケースで、色々想定は出来ますがハッキリした答えが分からなく迷うことがしばしばあります。。

だと思います。
今では、Internet公開講座を開いてるUnivercityも多いので、そうした、講義を受講して、自らの『解』を得るのも、一つの『道』ではないでしょうか。

『システムの要求値』から、『自らが、見つけ出し、自らが、確信し得た』ものを『まずは良し』とし、、、『壁』を感じた時、新た道を探ることになります。

小生も、直近で、先の状況にあって、、、
.netは、この歳になって、関わっても、もう、手遅れと判断し、
perlはかじったがrubyは知らない、
javaは、四六時中、頭から離れない、
phpは、eccubeでどっぷり、

で、clickを採用した訳ですが、、、もう少し、早く、nanasess様からの提言を得ていたら、選択結果は、変わっていたかも知れない。

が、小規模andイントラネット内だったので、Smartyより、Velocityということで、、、結果は同じだったでしょうが。。。


『ハッキリした答え』は、
・システム構築はGUIと口頭指示(キーボード改めマイク)
・クラッカー対策は自動構築
で、、、Developderは構築案件の実装に集中するのみ、、、
なのですが、我々が『世』に『存在する内に実現される』かどうかは微妙、、、と、いったところでしょうか。。。