10.Spring+SpringMVC+JdbcTemplate統合

10698 ワード

私は多くの企业级の応用开発、SSHの统合などの本を书いたことがあって、普通のこのような本はとても厚くて、中にはいくつかのプロジェクトの统合の例が含まれて、一目で过去を见て、深くて、本当に手に入れてよく考えて、突然何もないことを発见して、すべてコードの贴り付けで、原理の実际の少ないことを言います.もちろん私の言うことはもっと浅いですが、大丈夫です.まず大体を理解して、それから実際のプロジェクトの中で絶えず練習して、絶えず他の人のアーキテクチャの知識を吸収して、それからゆっくりと自分のものに変えなければなりません.そうすれば、自分のレベルは大幅に向上します.国内でのプログラミングは互いにパクリしたり、参考にしたりする過程であり、誰が参考にしているのか、誰が牛人なのか.
ここでも統合について話しますが、統合の内容は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%の状況はプロジェクトが大きくなくて、開発者は数人で、このような状況の下で、直接実現すればいいので、ショーアーキテクチャのハイエンドを使わないで、手間を省くのが最も主要です.
ソースのダウンロード
本工事の詳細ソース