10.Spring+SpringMVC+JdbcTemplate統合
10698 ワード
私は多くの企业级の応用开発、SSHの统合などの本を书いたことがあって、普通のこのような本はとても厚くて、中にはいくつかのプロジェクトの统合の例が含まれて、一目で过去を见て、深くて、本当に手に入れてよく考えて、突然何もないことを発见して、すべてコードの贴り付けで、原理の実际の少ないことを言います.もちろん私の言うことはもっと浅いですが、大丈夫です.まず大体を理解して、それから実際のプロジェクトの中で絶えず練習して、絶えず他の人のアーキテクチャの知識を吸収して、それからゆっくりと自分のものに変えなければなりません.そうすれば、自分のレベルは大幅に向上します.国内でのプログラミングは互いにパクリしたり、参考にしたりする過程であり、誰が参考にしているのか、誰が牛人なのか.
ここでも統合について話しますが、統合の内容はSpring+SpringMVC+JdbcTemplateで、Springシリーズで、統合も非常に簡単です.
pom.xml依存
ここには新しいものはなく、SpringMVCの依存と同じです.
Web.xml構成
これはweb起動の初期構成で、この中には3つのセグメントが含まれています.1つ目はlistenerでspringをロードする構成を起動することです.2つ目はシステムを設定するコードです.これはフィルタで完成します.3つ目はSpringMVCの起動構成です.簡単で、汎用的です.大きなプロジェクトでも小さなプロジェクトでも、基本的にはそうです.覚えておいてください.
applicationContext.xml
Springのプロファイル、データソースの設定、jdbcTemplateの設定、トランザクションの設定も古典的で、ほとんどのプロジェクトもこのように構成されています.
servlet-context.xml
これはSpringMVCの構成であり、最も核心的なものでもある.
残りは、モデル、dao、service、controllerなど、Staffに対応するいくつかのクラスです.これらは簡単ですから、言わないでください.
次に,実際のプロジェクトにおけるdaoとサービス層のインタフェースの問題について述べる.
多くの本では、このブロックを話すときに、daoのインタフェースを確立してから、対応する実装implを確立すると書いています.具体的には、なぜそうするのか、柔軟性があるからです.
柔軟性は抽象的な概念であり、何が柔軟なのか、何が柔軟ではないのか、明確な定義がない.私たちは開発の中で多くの教科書のテンプレートに従って、まずインタフェースを創立して、それから実現類を書きます.柔軟な特性を体現しているかどうかは、感じていないようですが、唯一の考えはハイエンドの大気レベルで、コードが手に入ることができて、コードはインタフェース向けのプログラミングで、具体的な実現向けではありません.
私の理解を話します.インタフェース向けのプログラミングはハイエンドの話題で、一般的なアーキテクチャはそう思っています.私はインタフェースだけを書いて、勝手に誰かに書いてもらうことを実現すればいいのです.sshというアーキテクチャの中で、実装クラスが1つしかないと、インタフェースを書く必要がなく、面倒で、インタフェースのメリットも現れません.つまり、直接実装プログラミングに向いているということです.例えば、StaffDao、StaffServiceは対応する実装クラスであり、多くのコードと時間を節約することができます.もちろん、プロジェクトが大きくなく、開発者が少ない場合が前提です.プロジェクトが非常に大きく、開発チームも多くの人がいる場合、インタフェースのメリットが現れ、インタフェースファイルを直接見て具体的にどのような実現があるかを知ることができます.多くの設計モードを使用すると、インタフェースは避けられないので、sshの範疇ではありません.
簡単に言えばプロジェクトが簡単で、人が少なくて、インタフェースを使わないで、プロジェクトはとても大きくて、人も多くて、インタフェースを使って、規範化します.多くの人にとって、90%の状況はプロジェクトが大きくなくて、開発者は数人で、このような状況の下で、直接実現すればいいので、ショーアーキテクチャのハイエンドを使わないで、手間を省くのが最も主要です.
ソースのダウンロード
本工事の詳細ソース
ここでも統合について話しますが、統合の内容はSpring+SpringMVC+JdbcTemplateで、Springシリーズで、統合も非常に簡単です.
pom.xml依存
UTF-8
4.3.3.RELEASE
org.springframework
spring-core
${spring.version}
org.springframework
spring-beans
${spring.version}
org.springframework
spring-aspects
${spring.version}
org.springframework
spring-aop
${spring.version}
org.springframework
spring-context
${spring.version}
org.springframework
spring-context-support
${spring.version}
org.springframework
spring-jdbc
${spring.version}
org.springframework
spring-test
${spring.version}
org.springframework
spring-web
${spring.version}
org.springframework
spring-webmvc
${spring.version}
jstl
jstl
1.2
javax.servlet
javax.servlet-api
3.1.0
mysql
mysql-connector-java
5.1.18
com.alibaba
druid
1.0.25
junit
junit
4.12
ここには新しいものはなく、SpringMVCの依存と同じです.
Web.xml構成
org.springframework.web.context.ContextLoaderListener
contextConfigLocation
classpath:applicationContext.xml
encodingFilter
org.springframework.web.filter.CharacterEncodingFilter
encoding
utf-8
forceEncoding
true
encodingFilter
*.htm
springMVC
org.springframework.web.servlet.DispatcherServlet
contextConfigLocation
classpath*:/servlet-context.xml
1
springMVC
*.htm
これはweb起動の初期構成で、この中には3つのセグメントが含まれています.1つ目はlistenerでspringをロードする構成を起動することです.2つ目はシステムを設定するコードです.これはフィルタで完成します.3つ目はSpringMVCの起動構成です.簡単で、汎用的です.大きなプロジェクトでも小さなプロジェクトでも、基本的にはそうです.覚えておいてください.
applicationContext.xml
Springのプロファイル、データソースの設定、jdbcTemplateの設定、トランザクションの設定も古典的で、ほとんどのプロジェクトもこのように構成されています.
servlet-context.xml
これはSpringMVCの構成であり、最も核心的なものでもある.
残りは、モデル、dao、service、controllerなど、Staffに対応するいくつかのクラスです.これらは簡単ですから、言わないでください.
次に,実際のプロジェクトにおけるdaoとサービス層のインタフェースの問題について述べる.
多くの本では、このブロックを話すときに、daoのインタフェースを確立してから、対応する実装implを確立すると書いています.具体的には、なぜそうするのか、柔軟性があるからです.
柔軟性は抽象的な概念であり、何が柔軟なのか、何が柔軟ではないのか、明確な定義がない.私たちは開発の中で多くの教科書のテンプレートに従って、まずインタフェースを創立して、それから実現類を書きます.柔軟な特性を体現しているかどうかは、感じていないようですが、唯一の考えはハイエンドの大気レベルで、コードが手に入ることができて、コードはインタフェース向けのプログラミングで、具体的な実現向けではありません.
私の理解を話します.インタフェース向けのプログラミングはハイエンドの話題で、一般的なアーキテクチャはそう思っています.私はインタフェースだけを書いて、勝手に誰かに書いてもらうことを実現すればいいのです.sshというアーキテクチャの中で、実装クラスが1つしかないと、インタフェースを書く必要がなく、面倒で、インタフェースのメリットも現れません.つまり、直接実装プログラミングに向いているということです.例えば、StaffDao、StaffServiceは対応する実装クラスであり、多くのコードと時間を節約することができます.もちろん、プロジェクトが大きくなく、開発者が少ない場合が前提です.プロジェクトが非常に大きく、開発チームも多くの人がいる場合、インタフェースのメリットが現れ、インタフェースファイルを直接見て具体的にどのような実現があるかを知ることができます.多くの設計モードを使用すると、インタフェースは避けられないので、sshの範疇ではありません.
簡単に言えばプロジェクトが簡単で、人が少なくて、インタフェースを使わないで、プロジェクトはとても大きくて、人も多くて、インタフェースを使って、規範化します.多くの人にとって、90%の状況はプロジェクトが大きくなくて、開発者は数人で、このような状況の下で、直接実現すればいいので、ショーアーキテクチャのハイエンドを使わないで、手間を省くのが最も主要です.
ソースのダウンロード
本工事の詳細ソース