【Java】DIコンテナって本当に便利か？

**デフォルトの名無しさん** · 2008/08/20(水) 23:23:26

インターフェースクラスやら設定やら増えまくって
かなりめんどくなってんだけどｗ

**デフォルトの名無しさん** · 2010/01/06(水) 21:20:18

ＧＤＩなら…

**デフォルトの名無しさん** · 2010/01/07(木) 10:17:34

三菱GDIエンジン

**デフォルトの名無しさん** · 2010/01/07(木) 22:44:22

>>396
WebBeansの頃から空気だろ

**デフォルトの名無しさん** · 2010/01/09(土) 05:03:49

CDIは、Tomcatとか各サーバーが標準装備するようになったら他のDIコンテナいらなくなりそう。
CDIのせいで一番最初に滅びるのはEJBだが。

**デフォルトの名無しさん** · 2010/01/09(土) 08:54:16

@TransactionAttributeはjavax.ejbだから滅びないよ

**デフォルトの名無しさん** · 2010/01/09(土) 13:53:11

>>400
CDIはTomcat6で今でも動いてるよ
JavaSEでも動いてSwingのコンポーネントに使えるサンプル付属してるくらい

**デフォルトの名無しさん** · 2010/01/09(土) 14:42:50

>>402
Tomcatが「標準装備」するようになったら、だろ
自分でライブラリ突っ込めば動くってんじゃ誰も使わんよ
俺はTomcatが標準装備してもCDIが流行るとは思わんけどな

**デフォルトの名無しさん** · 2010/01/09(土) 15:33:46

SpringもGuiceもSeasar2も標準装備はしてないよね？

**デフォルトの名無しさん** · 2010/01/09(土) 15:47:34

後発が同じ条件で流行ると思ってるのか？
EJB3だって流行ってないだろ？3.1だって流行らないよ
理由なきJavaEEアレルギーはまだまだ根強い

**デフォルトの名無しさん** · 2010/01/09(土) 16:01:54

EJBはサーブレットコンテナだけで動かないでしょ

**デフォルトの名無しさん** · 2010/01/09(土) 16:11:06

OpenEJB突っ込めば動く

**デフォルトの名無しさん** · 2010/01/17(日) 11:42:25

CDI手軽すぎ。でもトータルで見るとSeasarが勝る。

**デフォルトの名無しさん** · 2010/01/18(月) 06:45:59

学習コストでまける

**デフォルトの名無しさん** · 2010/01/19(火) 17:07:41

FFY最強！

**デフォルトの名無しさん** · 2010/10/04(月) 04:35:34

EE6でJavaは完成された感がある。
気に入らない人はまだまだ居そうだけど。

**ななし。** · 2011/07/27(水) 19:32:41.18

カ　オ　ス　ラ　ウ　ン　ジ　ゆ　る　せ　な　ぁ　い　ー

**デフォルトの名無しさん** · 2011/10/26(水) 20:17:30.57

仕様と実装を切り離す

**デフォルトの名無しさん** · 2012/01/02(月) 07:03:20.58

DIコンテナって2種類に分類されると思うんだ。以下あってる？

1. 型（inteface）に対するIOC(Guice)
2. 保有クラスに対するIOC(Spring)

(1)はinterfaceの保有クラスを区別せず1種類の実装が提供される。
(2)はinterfaceの保有クラスによって実装クラスが違う可能性がある。

**デフォルトの名無しさん** · 2012/01/02(月) 07:11:26.86

たとえば以下のような例の場合、
Guice系の場合にはインターフェースに対する実装の提供を１つだけ書いて
全てのIServiceに同じ実装が渡される。
Spring系の場合にはインターフェースに対する実装の提供を
コンテナからHogeを生成した場合、Mogeを、Kogeを生成した場合と3種書いて
保有クラス(Hoge,Moge,Koge)によってIServiceに違う実装が渡される。

class Hoge {
IService service;
}

class Moge {
IService service;
}

class Koge {
IService service;
}

**デフォルトの名無しさん** · 2012/01/02(月) 10:23:11.80

意味がよくわからん
guiceはintefaceと実装が一対一の関係「専用」のDIであるということを言ってる？
そういう意味なら違う
その場合は実装をアノテーションで指示するようになってる

**デフォルトの名無しさん** · 2012/01/02(月) 13:10:41.09

>>416
＞guiceはintefaceと実装が一対一の関係「専用」のDIであるということを言ってる？
うん、そういうこと。@Namedを使う抜け穴があるけど、それはguice系DIの思想的に
望ましくないと思うんだ。

intefaceと実装が一対一の関係だから実装を変更するときは
アプリケーション中でそのinterfaceに対する実装が一括で変更される。
そんなinterface単位の一括管理がguice系の方向性だと思うんだ。

**デフォルトの名無しさん** · 2012/01/02(月) 13:15:58.26

>>417
抜け穴ってｗ
一対一じゃ使い物になんないだろ
それ実装だけで開発するのと同じ事じゃんｗ

**デフォルトの名無しさん** · 2012/01/02(月) 13:23:52.18

続き

対してspringなどはinterfaceを使っているクラス単位で管理すると思うんだ。
例えば実装クラスを入れ替える場合、interfaceをフィールドに持っていたり
使っているクラス(bean)毎に設定を変更する。
抜け穴があるにしろ、基本的にDI箇所が増えるほど
設定が増える代わりに１つ１つ細かく指定できるのが利用クラス(bean)単位のDI

**デフォルトの名無しさん** · 2012/01/02(月) 13:31:53.96

>>418
説明がよくなかったかな。。。
例えばモックから完成クラスへ入れ替える、
あるいはMySQLからOracleDBに入れ替えるような、
そのインターフェースに対してアプリケーション中が一気に入れ替える
リソースの変更的な入れ替えのためにはGuiceは向いてるけど、

Buttonインターフェースに対してGreenButton, RedButtton, BlueButton
どれかを生成するストラテジーパターンみたいなものには向いていなくて、
仮にそれをするならわざわざIGreenButton, IRedButton, IBlueButtonみたいに
別々のインターフェースを作るのがGuice系の正しい使い方なんじゃないかな？

**デフォルトの名無しさん** · 2012/01/02(月) 13:37:47.57

>>420
いやーアノテーションでやるでしょそれは
IGreenButton等々はかなりまずいスタイルだよね・・・
インターフェイスに対してプログラミングするスタイルを完全にスポイルしちゃう
springはよく知らないけど、
あるinterfaceに対するデフォルトのバインディングを指定することもできないの？

**デフォルトの名無しさん** · 2012/01/02(月) 13:48:16.33

すると単なるIoCのFactoryクラス、つまりinterfaceなんか別に必須ではなくて
注入される側のクラスから見えないだけのFactoryクラスとして側面をもつのが
spring系DIで、

interface必須でinterfaceによる固い設計、実装クラス一括管理が
guice系DIの特徴に見えると思います。

**デフォルトの名無しさん** · 2012/01/02(月) 13:59:52.82

＞あるinterfaceに対するデフォルトのバインディングを指定すること
Guiceにとってはこちらが「基本」ですが、
Springにとっては「そういうのもできる」という立場ではないかと。

逆にGuiceで@Namedを使うようなパターンに対しては
Springにとってはこちらが「基本」ですが、
Guiceにとっては「そういうのもできる」という立場ではないでしょうか。

**デフォルトの名無しさん** · 2012/01/03(火) 10:54:33.00

DIはユニットテストのモック差し替えぐらいにしか使えないという記事を読んで、
やはりそういう用途にDIの概念が特化するならば、Guiceの@Namedみたいなiocコンテナ
の使い方はDIとは別の概念として切り分けられるべきではないかなと思た。

**デフォルトの名無しさん** · 2012/01/03(火) 13:32:47.27

DIよりもAOPがメインだよな
DIコンテナの用途って

**デフォルトの名無しさん** · 2012/01/03(火) 16:35:15.29

DIの方がメインでは？

**デフォルトの名無しさん** · 2012/01/03(火) 23:14:35.03

俺もあくまでDIの方がメインだと思う。

**デフォルトの名無しさん** · 2012/01/04(水) 08:38:37.47

実装の切り離し以外の役割を背負いすぎてるのが
学習時の混乱をもたらしてると思う

DIコンテナっぽいものをJavassistの練習で作ろうとしたところ
DIってどうあるべきだ？と考え出したところで停滞してしまったｗ

**デフォルトの名無しさん** · 2012/01/22(日) 19:01:48.77

やっぱDIコンテナ使う人って、とりあえずなんかクラス作るときは
例外なしにインタフェースかぶせとくもんなの？

今のプロジェクトはそうなってるけど、ユニットテストもないし
実装もすべて一個なんだから、もう密結合でもよくね？って気がすごくしてるんだけど

**デフォルトの名無しさん** · 2012/01/22(日) 19:38:29.82

そりゃ、ただの思い込みor実装上(AOPの方式とか)の制約じゃねーの？

俺は本当にプロバイダーモデルが必要な所しかInterfaceの分離はしないし、
テストに関しては黒魔術で対応してる。

**デフォルトの名無しさん** · 2012/01/23(月) 14:44:29.86

>>429
自分はいわゆるコントローラ(サービス)クラスとかDaoクラスであれば、
最初は実装クラスが1つしかなくても、例外なくインターフェースかぶせておくようにしている。

あとから、実装クラスを変えたくなった時や複数のバリエーションの実装クラスを作りたくなったとき、
context.xml で切り替えるだけで、プログラムを修正しないですむので、
プロジェクトの終盤で大きな変更を加えなければならなくなったときに、だいぶ助かったことがある。

例：
たとえば Dao で、インターフェース FooDao があったとして、
最初は iBatis で作っていたが(FooDaoIbatisImpl)、
一部独自に実装したくなった時は、FooDaoHogeImpl というように、FooDao を使った
別の実装クラスを作る。

context.xml で、bean id="fooDao" class=".." のところを FooDaoHogeImpl に変更すればいいので、
サービスオブジェクト側からは、変更を気にしなくて済む。

これでパフォーマンスチューニングをやったり、Dao の取得先を RDB から KVS とかに切り替えたりした。

**デフォルトの名無しさん** · 2012/01/24(火) 19:58:47.06

>やっぱDIコンテナ使う人って、とりあえずなんかクラス作るときは
>例外なしにインタフェースかぶせとくもんなの？

そうしてもいいぐらい粒の大きいクラスにしかDIしないこと

**デフォルトの名無しさん** · 2012/01/25(水) 19:44:03.96

何十とあるControllerやService、Daoに対して、例外無しに全てIFを用意するのか？、っとい疑問が生まれること自体は、まあ普通だと思う。

**デフォルトの名無しさん** · 2012/02/16(木) 17:08:25.22

必要なところをinterfaceに変えるのって手間掛かるか？
IDEのリファクタリング機能とか、無くても一旦コンパイルエラーにして
置換掛けていけばいいだけだし

必要になってからinterfaceにしても別によくね

**デフォルトの名無しさん** · 2012/02/17(金) 10:16:39.50

DIの利点ってやっぱテスト部分なのかね

**デフォルトの名無しさん** · 2012/02/17(金) 20:52:25.87

インジェクション設定が増えすぎるアンチパターンを懸念すると
テストの設計とDIでセットにするのが良いかもしれん

**デフォルトの名無しさん** · 2012/02/23(木) 01:44:38.83

interfaceを書きながら設計していく感じが多いかな
implするクラスも同時に書いていくと、設計が終わる頃にはスケルトン＋モックにもなるクラスができてる

**デフォルトの名無しさん** · 2012/02/23(木) 13:50:41.31

>何十とあるControllerやService、Daoに対して
なんで一対一でinterface用意する必要があるの…？
根本的にわかってないとしか言いようがない

**デフォルトの名無しさん** · 2012/02/23(木) 21:53:45.88

一対一にしないならDIやる意味なくない？

**デフォルトの名無しさん** · 2012/02/23(木) 22:21:45.78

インターフェイスをDIのタグとして使ってるってことかｗ

**デフォルトの名無しさん** · 2012/02/24(金) 18:50:12.83

DIって言葉も、なんかMVCと同じでぼくの使ってる最強のDIみたいなのが十人十色で意思疎通難しいし
もうNGワードにしたほうがいいんじゃないか

**431** · 2012/02/26(日) 21:41:06.65

>>439
開発当初は1対1しかないかもしれないけど、
あとから増える場合もあるので、そういった時には、インターフェースと実装クラスを分けておいてよかったと思うよ。

まぁ、これから作ろうとしているシステムが、使い捨て(寿命が短い)であまり変更を考慮しなくていい場合と、
ある程度長くなりそうな場合とで、手間とのトレードオフもあると思うけど。

**デフォルトの名無しさん** · 2012/02/26(日) 21:53:56.03

流れを誤読しとる？

**デフォルトの名無しさん** · 2012/02/26(日) 22:05:10.19

>>442
使い捨てがどうのともっともらしいことを言っているけど、
単に実装をIFを分離すべきポイントをちゃんと設計出来る能力が無いから
とりあえずなんでも分離しておく、っと言っているようにしか聞こえない。

そんなんで良いのか？

**デフォルトの名無しさん** · 2012/02/27(月) 08:57:55.64

DIのために一対一にするくらいならクラスを指定してDIすればいいだろってこと

**431** · 2012/02/27(月) 15:49:00.65

>>444
そう言われると反論できない。
突貫工事が多いから、とりあえず *Dao と *Service は
インターフェースと実装クラスに分けとけ、というルールを決めて、
開発に着手していたことは多かったな。

いちいち
・こういうケースは分離しましょう
・こういうケースは分離しなくていいです
というルールを考えている余裕がなかったので。

**デフォルトの名無しさん** · 2012/02/27(月) 16:39:07.27

そういう機械的な設計でいいと思うけどね。
堅実というか無難というか。

**デフォルトの名無しさん** · 2012/02/27(月) 19:59:53.91

実装クラスでメソッド追加した際に
インターフェイス側に宣言コピペするだけだしな

ファイル分けるもの面倒臭い
public interface A {
　　void f();
　　public static class Imp implements A {
　　　　public void f(){}
　　}
}

**デフォルトの名無しさん** · 2012/02/27(月) 23:02:03.47

なんかよくわからんなー
DIとなんの関係がある話なのかすらよくわかんない
Cのプロトタイプ宣言の話聞いてるみたいだ

**デフォルトの名無しさん** · 2012/02/27(月) 23:09:58.39

DIで注入される側
FooServiceImplならFooService型の定義になってて
BarServiceImplならBarService型の定義…みたいなことやってるってこと言ってるの？

**デフォルトの名無しさん** · 2012/02/27(月) 23:15:39.88

いや例がよくないｗごめん

**デフォルトの名無しさん** · 2012/02/27(月) 23:18:58.00

もうDaoでインターフェイスを分離する意味ないだろ
昔ならモックに差し替えるのに必要だったが

**デフォルトの名無しさん** · 2012/02/28(火) 23:46:53.79

intra-martの人達ってまだS2押してんの？

**デフォルトの名無しさん** · 2012/04/19(木) 00:58:00.99

>>140
>>351
>>444
話が合いそうだ

・直列化とビルダーパターン使うべきポイント
・マクロやジェネレータ使えばいいんじゃね？ってポイント
・なぜプログラムの修正をそんなに怖がる？ってポイント
・なぜファクトリの数行を面倒臭がる？（コード書けば言語解析による依存関係調査が可能だし、可読性も高まるのに）

って、結構どうでもいいところでDI使ってる人が沢山いる。

結局、普通のオブジェクト指向に対するシンタックスシュガーに過ぎないので、
経験のない人間が下手に使うと、どう再利用すればいいのか分からない、ゴミ山のような小さいクラス群と
環境によって内容が違う定義ファイルに道を迷わされる。。。

労働集約型産業やりたいのなら、COBOLとか実は良い言語だぜ？

**デフォルトの名無しさん** · 2012/08/18(土) 05:07:00.19

DIコンテナ使ってるのに結局ダウンキャストしてるとか、
それを避けるために（？）インターフェースと実装を１：１にして、同時にメンテしていくとか
そんな使われ方をしている所にしか出会ったことがないんで、考察が足りないかもしれないけど

DIコンテナって、上手く使えば便利なのは分かるんだけど、
publicメソッドの一つも足すことができないし、拡張性が落ちる気がするんだよね。
上の例みたいに、インターフェースと実装を１：１にすればできるけど、
その状況って単に、DIコンテナ使いたいからインターフェースと実装を分離してる感じになっちゃってるし、きもい。

作って終わりならいいけど、拡張をしていく可能性を残すなら、
そう簡単に導入できるものじゃない気がするんだよなぁ。

**デフォルトの名無しさん** · 2013/02/08(金) 12:54:44.22

DBfluteだのJBossだのJava界隈はまともに動かなかったりやる事増やしたりするゴミばっかだな

**デフォルトの名無しさん** · 2013/02/08(金) 13:10:11.56

http://event.seasarfoundation.org/sc2009white/viewAttachment.do?_pageName_=Session&;_fileName_=sc2009white_s406_4_hot.pdf

これ読んでると色々馬鹿馬鹿しくなるね

**デフォルトの名無しさん** · 2013/02/24(日) 16:07:14.97

DIってsetter使えば要らないよね？
AOP目的で使ってる人いるみたいだけど、ならsetter+AOPで良くてDI不要じゃん

**デフォルトの名無しさん** · 2013/02/24(日) 16:40:11.43

DIすることとDIコンテナを使うことは区別するべきだと思う。

「setter使えば」が何を意味しているのかイマイチ判然としないけれども、setter使って
サービス等の実装オブジェクトをセットするという意味ならそれは他でもないDIだと思う。

DI自体はDIコンテナの使用の有無に関わらず有用な設計パターンの一つだと思うよ。

あとはブートストラップに実装のsetを列挙するかそれともDIコンテナ使うかの、注入作業
の実装方法の違いに過ぎないと思う。
注入するものとされるものが増えてきて、autowireなど規約による自動注入の類を使い
始めるとDIコンテナも便利だと思う。

**457** · 2013/02/24(日) 20:24:51.85

理解が深まりましたm(__)m

**デフォルトの名無しさん** · 2013/02/24(日) 20:25:24.35

457 -> 458

**デフォルトの名無しさん** · 2013/12/28(土) 23:07:01.79

うん

**デフォルトの名無しさん** · 2014/03/02(日) 07:19:45.70

DIでインジェクションするクラスってさ
基本的にシングルトンになると思ってるんだけど
あってる？

**デフォルトの名無しさん** · 2014/03/05(水) 21:59:28.30

>>463
何で？親インスタンス1に対して子インスタンス一つ出来るよね？

**デフォルトの名無しさん** · 2014/03/06(木) 20:13:38.55

その親インスタンスも一個でしょ？

**デフォルトの名無しさん** · 2014/03/06(木) 20:28:00.99

謎が深まりましたm(__)m

**デフォルトの名無しさん** · 2014/03/06(木) 22:54:00.97

たいていのDIの実装が、シングルトンをデフォルトにしているっていうだけの話ではなくて？

インスタンス管理がHTTPコンテキストのものだと、シングルトンに見えて実際はDynamic Proxyが
インジェクションされていて、本当の処理はHTTPコンテキストに格納された個々のインスタンスへ
デリゲートされている、なんてものもあるし。

**デフォルトの名無しさん** · 2014/03/15(土) 12:31:18.68

jmockit使えるようになってからは、主だったビジネスロジック部分でのDIはなくてもいいんじゃないかという結論に辿り着いた。
もちろん全部不要って意味じゃないけど、自前でnewすることは怖いことじゃない。

なんていうか、今後を考えてもまず必要のないことが明確にわかるような、
意味のないDIの使い方をしているプロジェクト、多すぎると思う。

**デフォルトの名無しさん** · 2014/03/15(土) 12:51:07.19

普通はデータベース・ファイルIO・外部システム連携部やAPI等をインターフェースにして
単体テスト時はモック、動作時にはDIで実装クラス注入というパターンだな

勘違いした人が全てのクラスに対してインターフェースを用意してDIとかやり始めると、
複雑度が跳ね上がって困ったことになる

**デフォルトの名無しさん** · 2014/03/18(火) 08:14:10.97

やっぱり使える場所ってかなり少ないはずなんだよな
その辺はマルチスレッドを使うときのパターンに近似していると思う

DIコンテナの開発元や布教者がむやみにあちこち使わせるような
悪質なチュートリアルや宣伝をしているのが原因ではないだろうか

**デフォルトの名無しさん** · 2014/03/18(火) 11:02:39.52

使える場所は限られるが、ありがちなWebアプリだと、
手続き的に何度も書かなきゃいけないとこはだいたいカバーできるから、
普及してるんだと思われる。

勿論、何でもかんでもDIでというのはおかしいが。

**デフォルトの名無しさん** · 2014/08/02(土) 11:50:17.01

>>463
インジェクションするインスタンスのライフサイクルを外部から設定できるのもDIの特徴の一つだよ。

考えられるライフサイクルは、以下とかかな
シングルトン
DIするごとにインスタンス生成
同スレッド中で同インスタンス

Webアプリケーションの場合、セッションやリクエストもあるね。

**デフォルトの名無しさん** · 2014/09/21(日) 11:50:29.01

おちんぽインジェクション！

**デフォルトの名無しさん** · 2014/11/04(火) 12:10:06.56

>>469
難易度って意味だと、
自動テストって何ですか、単体テストは画面から動かしました！
ってなのが蔓延ってて、
○○機能サービスってクラスに
viewの状態から、SQLIDを含んだ発行メソッドや、ユーティリティ以外の全メソッドが乗ってる

そんな現場だと、例外なく全てである
って言い切っちゃった方がすんなり行きそう
それが新しいルールだってことにして

**デフォルトの名無しさん** · 2015/12/19(土) 10:22:39.99

プログラマはMacを使ってるってマジ？
http://hayabusa3.2ch.net/test/read.cgi/news/1450395043/

**デフォルトの名無しさん** · 2015/12/19(土) 15:44:40.26

どこの部分をポリモる必要があるかちゃんと線引きしておかないと、DI導入してもただうっとうしいだけになるんだよな。

**デフォルトの名無しさん** · 2016/01/26(火) 21:19:13.12

仕様がふわふわしてる時には自衛の為にDIしたほうがいい

**デフォルトの名無しさん** · 2016/03/29(火) 08:59:52.53

サッカーブッシュ日本代表日程ぷあたん（しゅっちょうまいくろ教育長交代）春文執行40代売上差額シュガーチョコ
https://www.youtube.com/watch?v=NDq1QoJY0nY宇ドナルドアナリストパワーストーンコーチングとしまえん
サッカーブッシュ日本代表日程古本屋よしたけしゅっちょうちょこしゅがー
ディーラー税務署天才開発者死亡詰みヨミドクターマイクロサービス不足
サッカーブッシュ日本代表日程ぷあたんシフト光金さかい強制バイト人権侵害問題
春分資源執行ニューヨーク低原価ぼったステーキソルトレイク福岡横浜新橋奴隷課金パチシフト強制バイト問題新潟米センター生残
コスメ２４チャリティー隠れ40代生活保護プレイボーイバイトレードいたりあん接待問題
マスコミKARDローンケーオーサービス不足婚活パーティー寄付金執行原発ビジネス
FBIチャイニーズタイホテル売上事務所ガチャ決算ガチャキャンペーン（販売報道陣過激派組織向携帯最新情報提供終了
校長発言細心注意ノートン産廃エラー(著作権クレーム中国反応融資高額教育費)(中国捕鯨団体40代社員サッカーコメント
高額入学金ヤフウ新橋大学ヤフウ新橋理事長FX経費おじや50代資産ガリバズフィード40代エリート

**デフォルトの名無しさん** · 2016/04/29(金) 22:34:59.65

Unityでdecoratorパターンしたい場合はどういう風に設定を書けばいいんでしょうか
例えばコードで書くとこんな感じです
var co = new UnityContainer();
co.RegisterType<ILogger, Logger>();
co.RegisterType<IFoo>(new InjectionFactory(
c => new LoggingFoo(new Foo(), c.Resolve<ILogger>()
));
これをコードではなく設定ファイルで定義したいです

**デフォルトの名無しさん** · 2016/07/08(金) 23:15:32.94

39 仕様書無しさん 2016/07/08(金) 23:11:07.46
Oracle、Java EEから手を引く可能性も

http://s.news.mynavi.jp/news/2016/07/04/261/

**デフォルトの名無しさん** · 2016/09/23(金) 00:09:39.76

そもそもClass定義自体がファクトリのはず
なのに何故、いちいちフレームワークの助けが必要なのか。

DIは今後の言語で言語仕様自体に組み込まれ
消えていくだろう

**デフォルトの名無しさん** · 2016/09/23(金) 12:46:27.71

汎化が過剰だからフレームワークの助けが必要になるんじゃないかと
コードを自動生成したほうがマシな気がする

**デフォルトの名無しさん** · 2018/05/23(水) 23:01:01.60

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

6IEJF

**デフォルトの名無しさん** · 2018/07/04(水) 23:07:25.92

9WT

**デフォルトの名無しさん** · 2018/10/12(金) 17:13:29.26

保守