อธิบายสถาปัตยกรรมที่คุณใช้สำหรับเว็บแอปพลิเคชัน Java หรือไม่ [ปิด]


146

มาแบ่งปันสถาปัตยกรรมแอปพลิเคชันบนเว็บของ Java กันเถอะ!

มีสถาปัตยกรรมที่แตกต่างกันมากมายสำหรับเว็บแอปพลิเคชันซึ่งจะนำไปใช้งานโดยใช้ Java คำตอบสำหรับคำถามนี้อาจทำหน้าที่เป็นห้องสมุดของการออกแบบเว็บแอปพลิเคชันที่หลากหลายด้วยข้อดีข้อเสีย ในขณะที่ฉันรู้ว่าคำตอบจะเป็นอัตนัยลองเป็นเป้าหมายให้มากที่สุดเท่าที่จะทำได้และกระตุ้นให้เกิดข้อดีและข้อเสียที่เรามี

ใช้ระดับรายละเอียดที่คุณต้องการสำหรับอธิบายสถาปัตยกรรมของคุณ เพื่อให้คำตอบของคุณมีค่าอย่างน้อยที่สุดคุณจะต้องอธิบายเทคโนโลยีและแนวคิดหลักที่ใช้ในสถาปัตยกรรมที่คุณอธิบาย และสุดท้าย แต่ไม่น้อยเมื่อเราควรใช้สถาปัตยกรรมของคุณหรือไม่

ฉันจะเริ่ม ...


ภาพรวมของสถาปัตยกรรม

เราใช้สถาปัตยกรรม 3 ชั้นตามมาตรฐานแบบเปิดจาก Sun เช่น Java EE, Java Persistence API, Servlet และ Java Server Pages

  • วิริยะ
  • ธุรกิจ
  • การเสนอ

การสื่อสารที่เป็นไปได้ระหว่างเลเยอร์ถูกแทนด้วย:

Persistence <-> Business <-> Presentation

ตัวอย่างเช่นหมายความว่าเลเยอร์การนำเสนอไม่เคยโทรหรือทำการดำเนินการติดตามันทำผ่านเลเยอร์ธุรกิจเสมอ สถาปัตยกรรมนี้มีขึ้นเพื่อตอบสนองความต้องการของเว็บแอพพลิเคชันที่มีความพร้อมใช้งานสูง

วิริยะ

ดำเนินการสร้างอ่านอ่านอัปเดตและลบ ( CRUD ) ในกรณีที่เรากำลังใช้ ( Java คงทน API ) JPA และเราใช้ในปัจจุบันHibernateเป็นผู้ให้บริการการคงอยู่ของเราและใช้EntityManager ของมัน

ชั้นนี้จะแบ่งออกเป็นหลายชั้นซึ่งแต่ละชั้นเรียนกับข้อเสนอบางประเภทของหน่วยงาน (หน่วยงานที่เกี่ยวข้องกับการเช่นรถเข็นช็อปปิ้งอาจได้รับการจัดการโดยระดับความคงอยู่คนเดียว) และมีการใช้โดยเพียงหนึ่งเดียวและผู้จัดการ

นอกจากนี้ในชั้นนี้ยังเก็บหน่วยงาน JPAซึ่งเป็นสิ่งที่ชอบAccount, ShoppingCartฯลฯ

ธุรกิจ

ตรรกะทั้งหมดที่เชื่อมโยงกับฟังก์ชันการทำงานของเว็บแอปพลิเคชันอยู่ในเลเยอร์นี้ ฟังก์ชั่นนี้สามารถเริ่มต้นการโอนเงินสำหรับลูกค้าที่ต้องการชำระค่าสินค้าออนไลน์โดยใช้บัตรเครดิตของเขา / เธอ มันอาจจะเป็นการสร้างผู้ใช้ใหม่การลบผู้ใช้หรือการคำนวณผลลัพธ์ของการต่อสู้ในเกมบนเว็บ

เลเยอร์นี้แบ่งออกเป็นหลายคลาสและแต่ละคลาสเหล่านี้มีคำอธิบายประกอบด้วย@Statelessเพื่อเป็นStateless Session Bean (SLSB) แต่ละ SLSB จะเรียกว่าเป็นผู้จัดการAccountManagerและตัวอย่างเช่นผู้จัดการอาจจะเป็นชั้นเรียนข้อเขียนดังที่ได้กล่าวเรียกว่า

เมื่อAccountManagerต้องการดำเนินการ CRUD จะทำให้การเรียกที่เหมาะสมไปยังอินสแตนซ์ของAccountManagerPersistenceซึ่งเป็นชั้นในชั้นคงอยู่ ภาพร่างคร่าวๆของสองวิธีAccountManagerสามารถ:

...
public void makeExpiredAccountsInactive() {
    AccountManagerPersistence amp = new AccountManagerPersistence(...)
    // Calls persistence layer
    List<Account> expiredAccounts = amp.getAllExpiredAccounts();
    for(Account account : expiredAccounts) {
        this.makeAccountInactive(account)
    }
}
public void makeAccountInactive(Account account) {
    AccountManagerPersistence amp = new AccountManagerPersistence(...)
    account.deactivate();
    amp.storeUpdatedAccount(account); // Calls persistence layer
}

เราใช้ธุรกรรมตัวจัดการคอนเทนเนอร์ดังนั้นเราไม่จำเป็นต้องทำธุรกรรมแบ่งเขตของตนเอง สิ่งที่เกิดขึ้นภายใต้ประทุนคือเราเริ่มทำธุรกรรมเมื่อเข้าสู่วิธี SLSB และส่งมอบ (หรือย้อนกลับ) ทันทีก่อนออกจากวิธี มันเป็นตัวอย่างของการประชุมเรื่องการตั้งค่า แต่เรายังไม่ต้องการอะไรนอกจากค่าเริ่มต้นที่จำเป็น

นี่คือวิธีการสอน Java EE 5 จาก Sun อธิบายคุณลักษณะธุรกรรมที่จำเป็นสำหรับ Enterprise JavaBeans (ของ EJB):

หากลูกค้ากำลังทำงานอยู่ภายในธุรกรรมและเรียกใช้วิธีการของ enterprise bean วิธีการดำเนินการภายในการทำธุรกรรมของลูกค้า ถ้าไคลเอนต์ไม่เกี่ยวข้องกับธุรกรรมคอนเทนเนอร์เริ่มต้นธุรกรรมใหม่ก่อนที่จะเรียกใช้วิธีการ

แอททริบิวที่จำเป็นคือแอททริบิวต์การทำธุรกรรมโดยนัยสำหรับวิธี bean ขององค์กรทั้งหมดที่รันด้วยการแบ่งส่วนธุรกรรมที่จัดการคอนเทนเนอร์ โดยทั่วไปแล้วคุณไม่ได้ตั้งค่าแอททริบิวที่จำเป็นเว้นแต่ว่าคุณต้องการแทนที่แอททริบิวการทำธุรกรรมอื่น เนื่องจากแอททริบิวธุรกรรมเป็นรายการคุณสามารถเปลี่ยนได้ในภายหลัง

การเสนอ

เลเยอร์การนำเสนอของเรามีหน้าที่รับผิดชอบ ... การนำเสนอ! รับผิดชอบส่วนต่อประสานผู้ใช้และแสดงข้อมูลต่อผู้ใช้โดยการสร้างหน้า HTML และรับข้อมูลผู้ใช้ผ่านคำขอ GET และ POST ขณะนี้เรากำลังใช้การรวมกันของ + Java Server Pages ( JSP ) ของServlet แบบเก่า

เลเยอร์เรียกเมธอดในผู้จัดการของเลเยอร์ธุรกิจเพื่อดำเนินการตามที่ผู้ใช้ร้องขอและเพื่อรับข้อมูลที่จะแสดงในหน้าเว็บ บางครั้งข้อมูลที่ได้รับจากชั้นธุรกิจเป็นชนิดที่มีความซับซ้อนน้อยลงเช่นString'และintegers และในเวลาอื่น ๆหน่วยงาน JPA

ข้อดีและข้อเสียกับสถาปัตยกรรม

ข้อดี

  • การมีทุกอย่างที่เกี่ยวข้องกับวิธีเฉพาะในการคงอยู่ในเลเยอร์นี้หมายความว่าเราสามารถสลับจากการใช้ JPA เป็นอย่างอื่นโดยไม่ต้องเขียนอะไรใหม่ในชั้นธุรกิจ
  • เป็นเรื่องง่ายสำหรับเราที่จะสลับเลเยอร์การนำเสนอของเราเป็นอย่างอื่นและเป็นไปได้ว่าเราจะทำถ้าเราพบสิ่งที่ดีกว่า
  • การปล่อยให้คอนเทนเนอร์ EJB จัดการขอบเขตการทำธุรกรรมนั้นดี
  • การใช้ + JPA ของ Servlet นั้นง่าย (เริ่มต้นด้วย) และมีการใช้เทคโนโลยีอย่างกว้างขวางและนำไปใช้ในเซิร์ฟเวอร์จำนวนมาก
  • โดยใช้ Java EE ควรจะทำให้มันง่ายขึ้นสำหรับเราที่จะสร้างระบบความพร้อมใช้งานสูงที่มีสมดุลภาระและไม่ผ่าน ทั้งที่เรารู้สึกว่าเราต้องมี

จุดด้อย

  • การใช้ JPA คุณอาจเก็บแบบสอบถามที่ใช้บ่อยเป็นแบบสอบถามที่มีชื่อโดยใช้@NamedQueryคำอธิบายประกอบในคลาสเอนทิตี JPA หากคุณมีความเกี่ยวข้องกับการคงอยู่ในคลาสการคงอยู่มากที่สุดเท่าที่จะเป็นไปได้เช่นเดียวกับในสถาปัตยกรรมของเราสิ่งนี้จะกระจายตำแหน่งที่ตั้งที่คุณอาจพบข้อความค้นหาเพื่อรวมเอนทิตี JPA ด้วย มันจะยากกว่าที่จะเห็นภาพรวมการดำเนินงานคงอยู่และยากที่จะรักษา
  • เรามีหน่วยงาน JPA เป็นส่วนหนึ่งของชั้นความเพียรของเรา แต่AccountและShoppingCartพวกเขาไม่ใช่วัตถุทางธุรกิจจริง ๆ หรือ มันทำแบบนี้เมื่อคุณต้องสัมผัสคลาสเหล่านี้และเปลี่ยนเป็นเอนทิตีที่ JPA รู้วิธีจัดการ
  • หน่วยงาน JPA ซึ่งเป็นวัตถุทางธุรกิจของเราถูกสร้างขึ้นเช่น Data Transfer Objects ( DTO ) หรือที่เรียกว่า Value Objects (VO's) ซึ่งส่งผลในรูปแบบโดเมน anemicเป็นวัตถุธุรกิจไม่มีตรรกะของตนเองยกเว้นวิธีการเข้าถึง ตรรกะทั้งหมดทำโดยผู้จัดการของเราในชั้นธุรกิจซึ่งส่งผลให้รูปแบบการเขียนโปรแกรมขั้นตอนมากขึ้น มันไม่ใช่การออกแบบเชิงวัตถุที่ดี แต่อาจไม่ใช่ปัญหาใช่ไหม (หลังจากการวางแนววัตถุทั้งหมดไม่ได้เป็นกระบวนทัศน์การเขียนโปรแกรมเพียงอย่างเดียวที่ส่งผลลัพธ์)
  • การใช้ EJB และ Java EE จะทำให้เกิดความซับซ้อนเล็กน้อย และเราไม่สามารถใช้ Tomcat ได้อย่างหมดจด (การเพิ่ม EJB micro-container ไม่ใช่Tomcat ล้วนๆ )
  • มีปัญหามากมายเกี่ยวกับการใช้ + JPA ของ Servlet ใช้ Google สำหรับข้อมูลเพิ่มเติมเกี่ยวกับปัญหาเหล่านี้
  • เนื่องจากธุรกรรมถูกปิดเมื่อออกจากชั้นธุรกิจเราไม่สามารถโหลดข้อมูลใด ๆ จากเอนทิตี JPA ที่กำหนดค่าให้โหลดจากฐานข้อมูลเมื่อจำเป็น (โดยใช้fetch=FetchType.LAZY) จากภายในเลเยอร์การนำเสนอ มันจะทำให้เกิดข้อยกเว้น ก่อนที่จะส่งคืนเอนทิตีที่มีฟิลด์ประเภทนี้เราจะต้องแน่ใจว่าได้โทรหาผู้ที่เกี่ยวข้อง อีกตัวเลือกหนึ่งคือการใช้ Java คงทน Query Language ( JPQL ) FETCH JOINและทำ อย่างไรก็ตามตัวเลือกทั้งสองนี้ค่อนข้างยุ่งยาก

1
ดูเหมือนว่าคุณตั้งแถบสูงเกินไปกับคำตอบของคุณเอง - มันอาจจะมีคนอื่น ๆ ท้อแท้ :)
Jonik

5
นอกจากนี้บางทีของคุณควรเป็นคำตอบปกติไม่ใช่ส่วนหนึ่งของคำถามเพื่อให้สามารถลงคะแนนพร้อมกับคำตอบอื่น ๆ ?
Jonik

คำถามนี้มีการอ้างอิงใน meta
D4V1D

คำตอบ:


20

ตกลงฉันจะทำ (สั้น) หนึ่ง:

  • Frontend: Tapestry (3 สำหรับโครงการเก่าและ 5 สำหรับโครงการใหม่)
  • ชั้นธุรกิจ: ฤดูใบไม้ผลิ
  • DAO's: Ibatis
  • ฐานข้อมูล: Oracle

เราใช้การสนับสนุนธุรกรรม Sping และเริ่มทำธุรกรรมเมื่อเข้าสู่เลเยอร์บริการแล้วส่งต่อไปยัง DAO call ชั้นบริการมีความรู้รูปแบบธุรกิจมากที่สุดและ DAO ก็ทำงาน CRUD ได้ค่อนข้างง่าย

บางสิ่งที่ซับซ้อนกว่าแบบสอบถามถูกจัดการโดยการสืบค้นที่ซับซ้อนมากขึ้นในแบ็กเอนด์ด้วยเหตุผลด้านประสิทธิภาพ

ข้อดีของการใช้ Spring ในกรณีของเราคือเราสามารถมีอินสแตนซ์ที่ขึ้นกับประเทศ / ภาษาซึ่งอยู่หลังคลาส Spring Proxy ขึ้นอยู่กับผู้ใช้ในเซสชั่นการใช้งานประเทศ / ภาษาที่ถูกต้องจะใช้เมื่อมีการโทร

การจัดการธุรกรรมมีความโปร่งใสเกือบจะย้อนกลับในข้อยกเว้นรันไทม์ เราใช้ข้อยกเว้นที่ไม่ได้ตรวจสอบมากที่สุด เราเคยทำการตรวจสอบข้อยกเว้น แต่ด้วยการเปิดตัวของฤดูใบไม้ผลิฉันเห็นประโยชน์ของข้อยกเว้นที่ไม่ถูกตรวจสอบเฉพาะการจัดการข้อยกเว้นเมื่อคุณทำได้ มันหลีกเลี่ยงจำนวนมาก "จับ / rethrow" สำเร็จรูปหรือสิ่งที่ "พ่น"

ขออภัยมันสั้นกว่าโพสต์ของคุณหวังว่าคุณจะสนใจสิ่งนี้ ...


คำตอบที่ดี! กระทู้นี้ดูเหมือนว่าจะดึงดูดปริมาณการเข้าชมน่าเสียดายที่คนอื่นไม่รู้สึกว่าพวกเขามีเวลาอธิบายสถาปัตยกรรมหรือมีเหตุผลอื่นที่ไม่เข้าร่วม

19

อุดมคติจากเทคโนโลยีการพัฒนาเว็บบน Java ในปัจจุบัน

เลเยอร์เว็บ:

HTML CSS + + + JQuery อาแจ็กซ์

ชั้นการประมวลผล RESTFul เว็บคอนโทรลเลอร์ / การกระทำ / คำขอ:

เล่น Framework

ตรรกะทางธุรกิจ / ชั้นบริการ:

ใช้ Pure Java Code ให้นานที่สุด สามารถผสมผสานบริการเว็บได้ที่นี่

ชั้นการแปลงข้อมูล XML / JSon:

XMLTool (ค้นหาด้วย Google Code), JSoup, Google GSon, XStream, JOOX (ค้นหาด้วย Google Code)

ชั้นความคงทน:

CRUD: JPA หรือ SienaProject หรือ QueryDSL / ข้อความค้นหาที่ซับซ้อน: JOOQ, QueryDSL


9

นี่คือ 5 เซ็นต์ของฉัน

การเสนอ

Android, Angular.JS WebClient, OAUTHv2

API

REST, Jersey (JAX-RS), Jackson (JSON de- / serialization), DTO-objects (แตกต่างจากโมเดลธุรกิจเชิงตรรกะ)

ตรรกะทางธุรกิจ

สปริงสำหรับ DI และการจัดการเหตุการณ์ วิธี DDD-ish ของวัตถุแบบจำลอง งานที่กำลังรันนานกว่านั้นจะถูกโหลดด้วย SQS ในโมดูลผู้ปฏิบัติงาน

DAO

โมเดลที่เก็บพร้อม Spring JDBC-templates เพื่อเก็บเอนทิตี Redis (JEDIS) สำหรับกระดานผู้นำโดยใช้รายการสั่งซื้อ Memcache สำหรับร้านค้า Token

ฐานข้อมูล

MySQL, Memcached, Redis


นี่คือสิ่งที่คล้ายกับสิ่งที่เราติดตามในโครงการของเราเช่นกัน! นอกจาก JBPM สำหรับเวิร์กโฟลว์ทางธุรกิจ ทำไมไม่มีฤดูใบไม้ผลิฉันสงสัย
ininprsr

ฉันควรทำการอัพเดทกับ arch ปัจจุบันของเรา: ปัจจุบันเราใช้ Spring DI และ JDBC-templates สำหรับ data-access layer
Pepster

6

สิ่งที่เราได้ติดตามในโครงการของเราคือ:

เทคโนโลยีส่วนหน้า

  • AngularJS
  • HTML5
  • CSS3
  • จาวาสคริ
  • Bootstrap 3

API

  1. ส่วนที่เหลือ
  2. JERSEY (JAX-RS)
  3. มั่นใจเหลือ
  4. บู๊ทสปริง
  5. แจ็คสัน
  6. ความปลอดภัยสปริง

ตรรกะทางธุรกิจ

  • ข้อมูลฤดูใบไม้ผลิ

  • ข้อมูล SPRING MongoDB

ฐานข้อมูล

  • MongoDB

เซิร์ฟเวอร์ (สำหรับการแคช)

  • Redis

4

เรายังคงใช้สแตก Struts-Spring-Hibernate ตามปกติ

สำหรับแอพในอนาคตเรากำลังมองหา Spring Web Flow + Spring MVC + Hibernate หรือ Spring + Hibernate + Web Services พร้อม Flex front end

คุณสมบัติที่แตกต่างของสถาปัตยกรรมของเราคือการทำให้เป็นโมดูล เรามีโมดูลจำนวนหนึ่งบางตัวเริ่มต้นด้วย 3 ถึงสูงสุด 30 ตารางในฐานข้อมูล โมดูลส่วนใหญ่ประกอบด้วยโครงการทางธุรกิจและเว็บ โครงการธุรกิจถือตรรกะทางธุรกิจและความเพียรในขณะที่เว็บถือตรรกะการนำเสนอ
ในระดับตรรกะมีสามชั้น: ธุรกิจความคงทนและการนำเสนอ
การพึ่งพา:
การนำเสนอขึ้นอยู่กับธุรกิจและความคงทน
ความคงทนขึ้นอยู่กับธุรกิจ
ธุรกิจไม่ได้ขึ้นอยู่กับเลเยอร์อื่น

โครงการธุรกิจส่วนใหญ่มีอินเทอร์เฟซสามประเภท (หมายเหตุ: ไม่ใช่ GUI เป็นเลเยอร์อินเตอร์เฟสโปรแกรมแบบ java)

  1. อินเทอร์เฟซที่งานนำเสนอที่ใช้เป็นไคลเอนต์
  2. อินเทอร์เฟซที่โมดูลอื่นกำลังใช้เมื่อพวกเขาเป็นไคลเอนต์ของโมดูล
  3. อินเทอร์เฟซที่สามารถใช้สำหรับวัตถุประสงค์ในการจัดการของโมดูล

บ่อยครั้งที่ 1 ขยาย 2 ด้วยวิธีนี้ทำให้ง่ายต่อการแทนที่การใช้งานโมดูลหนึ่งด้วยอีกโมดูลหนึ่ง สิ่งนี้ช่วยให้เรานำไปใช้กับลูกค้าที่แตกต่างกันและรวมได้ง่ายขึ้น ลูกค้าบางรายจะซื้อเฉพาะบางโมดูลและเราจำเป็นต้องรวมฟังก์ชั่นที่มีอยู่แล้ว เนื่องจากส่วนต่อประสานและการใช้งานแยกออกจากกันจึงเป็นเรื่องง่ายที่จะแผ่การใช้งานโมดูล ad-hock สำหรับไคลเอนต์นั้นโดยไม่กระทบต่อโมดูลที่ขึ้นต่อกัน และ Spring Framework ทำให้ง่ายต่อการฉีดการนำไปปฏิบัติต่าง ๆ

ชั้นธุรกิจของเราขึ้นอยู่กับ POJO แนวโน้มหนึ่งที่ฉันสังเกตคือ POJO เหล่านี้มีลักษณะคล้าย DTO เราต้องทนทุกข์ทรมานจากรูปแบบโดเมนโรคโลหิตจาง ฉันไม่แน่ใจว่าทำไมสิ่งนี้ถึงเกิดขึ้น แต่อาจเป็นเพราะความเรียบง่ายของโดเมนปัญหาของโมดูลของเราหลาย ๆ งานส่วนใหญ่เป็น CRUD หรือเนื่องจากนักพัฒนาต้องการที่จะวางตรรกะที่อื่น


3

นี่เป็นอีกหนึ่งสถาปัตยกรรมเว็บที่ฉันทำงาน:

ข้อกำหนดที่สำคัญอย่างหนึ่งคือแอปพลิเคชันควรสนับสนุนโทรศัพท์มือถือ / อุปกรณ์อื่น ๆ แอพพลิเคชั่นควรมีความยืดหยุ่นหรือยืดหยุ่นได้มากขึ้นต่อการเปลี่ยนแปลงของตัวเลือกเทคโนโลยี

ชั้นนำเสนอ:

  • JSP / JQuery (MVC ฝั่งไคลเอ็นต์)
  • Android พื้นเมือง
  • iPhone พื้นเมือง
  • เว็บมือถือ (HTML5 / CSS3 / การออกแบบที่ตอบสนอง)

  • Spring REST Controllers (สามารถเปลี่ยนเป็น JAX-RS)

ชั้นธุรกิจบริการ:

Spring @Service (สามารถเปลี่ยนเป็น Stateless EJB)

ระดับการเข้าถึงข้อมูล:

Spring @ Repository (สามารถเปลี่ยนเป็น Stateless EJB)

ระดับทรัพยากร:

หน่วยงาน Hibernate (JPA) (สามารถเปลี่ยนเป็น ORM ใด ๆ )

คุณสามารถค้นหาข้อมูลเพิ่มเติมเกี่ยวกับหนังสือเล่มหนึ่งซึ่งต่อไปนี้สถาปัตยกรรมนี้ที่นี่


2

IMHO พวกเราส่วนใหญ่มีส่วนร่วมกัน อย่างน้อยที่สุดใน back-end เรามีรูปแบบของ IOC / DI container และกรอบการคงอยู่ ส่วนตัวฉันใช้ Guice และ Mybatis สำหรับสิ่งนี้ ความแตกต่างคือวิธีที่เราใช้เลเยอร์ดู / UI / การนำเสนอ มี 2 ​​ตัวเลือกหลัก ๆ ที่นี่ (อาจมากกว่า) .. อิงตามการกระทำ (URL ที่แมปกับตัวควบคุม) และส่วนประกอบ ขณะนี้กำลังใช้เลเยอร์การนำเสนอที่อิงองค์ประกอบ (โดยใช้ประตู) มันเลียนแบบสภาพแวดล้อมเดสก์ท็อปอย่างสมบูรณ์แบบที่ฉันใช้ส่วนประกอบและเหตุการณ์ต่างจาก URL และตัวควบคุม ฉันกำลังค้นหาสาเหตุที่ฉันควรย้ายไปยังสถาปัตยกรรมตัวควบคุม URL นี้ (นั่นคือวิธีที่ฉันสิ้นสุดในหน้านี้) ทำไมโฆษณาที่เกี่ยวกับสถาปัตยกรรมที่สงบและไร้สัญชาติ

เพื่อตอบคำถามสั้น ๆ นี้: ฉันเขียนเว็บแอปพลิเคชั่นที่มีสถานะเป็นเฟรมเวิร์กส่วนประกอบที่ด้านบนของคอนเทนเนอร์ Guice IOC และใส่ข้อมูลในฐานข้อมูลเชิงสัมพันธ์โดยใช้ Mybatis


1

แตกต่างกันเล็กน้อยและฉันจะอ้างสิทธิ์สถาปัตยกรรม Java แบบแยกส่วนเพิ่มเติมที่นี่ เรามี:

  1. Spring WS / Rest / JSP ส่วนหน้า
  2. Spring MVC สำหรับตรรกะบริการธุรกิจที่มีตรรกะเลเยอร์การนำเสนอเช่นเดียวกับธุรกรรม Spring
  3. ส่วนต่อประสานบริการการสื่อสารบริการค้นหาผ่าน EJB ตามบริการธุรกิจ EJB ตั้งขอบเขตการทำธุรกรรมของตนเองที่สามารถเข้าร่วมธุรกรรม Spring ได้
  4. การใช้งานบริการคอมโพเนนต์, คอมโพเนนต์ Spring อีกครั้ง
  5. Integration layer, MyBatis สำหรับการรวมฐานข้อมูล, Spring WS สำหรับการรวมบริการเว็บ, เทคโนโลยีการรวมอื่น ๆ สำหรับบริการอื่น ๆ
  6. เฟรมหลักฐานข้อมูลบริการอื่น ๆ ที่เซิร์ฟเวอร์อื่น ...

นอกเหนือจากข้างต้นเรายังมีโมดูลไลบรารีที่ใช้ร่วมกันซึ่งเป็นผู้ให้บริการฟังก์ชั่นทั่วไปสำหรับ srevices ทั้งหมด

การใช้เลเยอร์ที่แตกต่างกันทำให้เราสามารถแยกการแยกส่วนและโมดุลที่เราต้องการ เรายังสามารถใช้พลังของ Java EE และ Spring ได้อย่างเต็มที่ ไม่มีอะไรขัดขวางเราจากการใช้ JSF สำหรับส่วนหน้าถ้าจำเป็น

เมื่อเทียบกับตัวอย่างสถาปัตยกรรมของ OP ฉันคิดว่านี่สามารถอธิบายได้ว่ามีสี่เลเยอร์หลักแทนที่จะเป็นสามชั้นแม้ว่าจะเป็นเกลียว


0

ฉันทำงานในโครงการที่ใช้รูปแบบผู้จัดการที่เข้มงวด ในอดีตฉันเป็นผู้สนับสนุนลำดับชั้นที่แข็งแกร่งซึ่งทุกอย่างลงตัวพอดีกับกล่องที่เรียบร้อย เมื่อฉันก้าวหน้าในอาชีพของฉันฉันพบว่ามันถูกบังคับในหลายกรณี ฉันเชื่อว่าการใช้ความคิดที่กระฉับกระเฉงยิ่งขึ้นต่อการออกแบบแอปพลิเคชันนำไปสู่ผลิตภัณฑ์ที่ดีกว่า สิ่งที่ฉันหมายถึงโดยการสร้างชุดชั้นเรียนที่แก้ปัญหาในมือ แทนที่จะพูดว่า "คุณสร้างผู้จัดการเพื่อสิ่งนี้หรือไม่"

โครงการปัจจุบันที่ฉันกำลังทำอยู่คือเว็บแอปที่มีการผสมผสานระหว่าง Spring MVC และการโทรแบบ RestEasy JSON / Ajax ฝั่งเซิร์ฟเวอร์ที่ฝังอยู่ในตัวควบคุมของเราเป็นระดับข้อมูลที่ง่ายต่อการเข้าถึงโดยใช้ JPA / Hibernate สำหรับการเข้าถึงฐานข้อมูลโดยตรงการเข้าถึง EJB บางส่วนและการโทรผ่านเว็บเซอร์วิส SOAP การผูกทั้งหมดนี้เข้าด้วยกันคือโค้ดจาวาคอนโทรลเลอร์ที่กำหนดเองซึ่งกำหนดว่าจะทำให้ซีเรียลนอะไรเป็น JSON และกลับไปที่ไคลเอ็นต์

เราใช้เวลาเกือบจะไม่พยายามสร้างรูปแบบที่เป็นเอกภาพแทนที่จะเลือกที่จะนำแนวคิด "เลวร้ายกว่าดีกว่า" มาใช้กับปรัชญาการออกแบบ Unix การที่ดีกว่าการระบายสีนอกเส้นและสร้างสิ่งที่สมเหตุสมผลได้เร็วกว่าการสร้างสิ่งที่ยึดติดกับคำสั่งการออกแบบที่เข้มงวด


0

คอมโพเนนต์ในWeb Application Architectureรวมถึง:

1: เบราว์เซอร์: การโต้ตอบกับลูกค้า

        HTML
        JavaScript
        Stylesheet

2: อินเทอร์เน็ต

3: เว็บเซิร์ฟเวอร์

        CSS
        Image
        Pages(Java render )

4: เซิร์ฟเวอร์แอปพลิเคชัน

        App Webapp (Java interaction)
        Others WebApps

5: เซิร์ฟเวอร์ฐานข้อมูล

        Oracle, SQL, MySQL

6: ข้อมูล

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.