Serviceクラスの設計について

[nanasess]

• Service の中で Form の処理をしない。 Controller の private or protected メソッドで事足りるはず。
• Service メソッドの引数に app を渡さない. DIを定義する段階で渡しているはず。 public $app も private で良いはず。
• オブジェクト引数の場合は, 必ず型パラメータをつける
• 仕様を明確にする意味でもメソッドコメントを正確に書く

[nanasess]

#630 で、 Controller のメソッドを Service に移動していますが、 ShoppingController でしか使用していないメソッドなので、わざわざ Service に移動しなくても良いと思います。。。
Service の考え方の違いだと思いますが。

[nobuhiko]

@nanasess
プラグインから、private or protected を拡張できるのであれば、それで問題ない気はしますがその辺りどうなんでしょう

[nanasess]

@nobuhiko 現状のプラグインの設計で、どれだけできるか精査できていないのですが、 Controller を継承するのであれば、 protected にしておけば問題ないかなと。
Service の場合は、移譲するような仕組みを作っておかないと、かえってプラグインから拡張しにくい気がするのですが、どうなんでしょう？

[nobuhiko]

@nanasess 自分も今がどうなってるのかさっぱりわからないので、どうなのかなーと。

[ttsuru]

Service と Repository の違いもすごく気になります。
DB系で本来はRepositoryにあるべきものがServiceにある気がします。

[nanasess]

@ttsuru 勉強不足で、 Repository の概念をよく理解していない(Data Access Object と同義だと思っている)のですが、 Service とは性格が異なるはずなので、混在しているのは良くないですね。

[ttsuru]

@nanasess
はい、ご指摘の認識で問題ないかと思います。

https://github.com/EC-CUBE/ec-cube/blob/master/src/Eccube/Service/OrderService.php#L229
たとえばこの辺りでしょうか。

[nanasess]

@ttsuru

https://github.com/EC-CUBE/ec-cube/blob/master/src/Eccube/Service/OrderService.php#L229
たとえばこの辺りでしょうか。

なるほど、これは値が取得できなかったらシステムエラーになってしまいますし、 Repository で処理しなければまずいですね。

[nanasess]

いろいろ調べてみると、 Repository と DAO の概念は異なるということがわかってきました。

• DAO はデータソースとオブジェクトとのマッピング
• Repository はドメインオブジェクトの概念であり、データソースには依存しない

参考)
http://blog.fukuchiharuki.me/entry/2014/12/29/110029

Repository という概念は、 Java でいうところの JPA や JDO にあたるものなのですね。
(Java では、これらも DAO と呼んでいました)

そういう観点からすると、 CSV や Yaml など、ファイル上のデータソースも Repository で抽象化して扱うのが正しいと思われますが、 Symfony ではどうなんでしょう？？
Doctrine に依存しない Repository を作ったりするものなのでしょうか。

[chihiro-adachi]

4系になって、ステートマシンやPurchaseFlow等抽象化された部分があります。
現状ではまた異なる課題がでてくるかと思われるため、いったんクローズします。