DIのコーディング方法、メリット(テストがしやすい(疎結合になるため)、コードがシンプルになる)はわかったのですがつかいどころがよくわかりません。
とりあえずプロパティがクラスのインスタンスになる場合はすべてDIしたほうがいいのでしょうか?
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
回答4件
0
https://www.ulsystems.co.jp/topics/025
はいかがでしょう?
私は参考になりました(しっくりきました)。
投稿2015/08/26 12:58
総合スコア87
0
個人的には、サーブレットを開発したときが一番しっくりきました。
その時は、JSP以外のJavaで作成した部分を、logic層、service層、dao層に分けていましたが、この間はすべてDIで疎結合にしました。
その結果ユニットテスト時には、dao層はデータからSQLが正常に作成されること、service層は、想定通りにdaoを呼ぶこと、logic層は、service層以降の後ろのレイヤが未作成状態でも、ビジネスロジックが正しいことを確認できました。
後、あまり無いことではありますが、DBを変更してDAO層を修正するとなっても、修正範囲がぐっと小さくなっていました。
投稿2015/08/27 13:28
総合スコア1038
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
ベストアンサー
ページ間でデータ渡ししたい場合や、セッション単位でデータを保持したい場合にDIが便利かと思います。
DIしたオブジェクトは各ページのBackingBean間でアクセス可能になりますし、保持するスコープ(期間)もSession、Request、Aplicationなど任意設定可能です。従来のSession変数保持や、Request渡しの方式に比べスマートなコーディングができると思います。
利用するプロパティ(インスタンス)がクラス内で閉じているのであれば、特にDIする必要は無いかと思います。但し、メモリーを大きく使用するインスタンスであればDIにより節約効果は有るかも知れません。
投稿2015/09/01 04:40
総合スコア1339
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
とりあえずプロパティがクラスのインスタンスになる場合はすべてDIしたほうがいいのでしょうか?
うーん。DIの使いドコロですが、数千行以上ある規模のソフトウェア開発でないと、嬉しさを実感しづらいかもしれません。過剰な抽象化はかえってソフトウェアの理解を妨げます。ベタで実装しつづけて、変更するといろんな所に問題がでてしまう、いわゆるもぐらたたきにあってみないと、疎結合だったり、コードがシンプルであったり、という利点が実感しづらいかもしれません。
投稿2015/09/01 04:34
退会済みユーザー
総合スコア0
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。