แอปพลิเคชันบริการเรียกฟังก์ชันฐานข้อมูลชั้น สถาปัตยกรรมไม่ดี?

สถานการณ์:

• สแต็ค: Java, Spring, Hibernate
• รุ่น: แอปพลิเคชันไคลเอนต์ - เซิร์ฟเวอร์
• รูปแบบ: Model-View-Controller (MVC)

คลาส Service Layer มีพฤติกรรมสามอย่าง:

1. บริการบางอย่างมีกฎเกณฑ์ทางธุรกิจภายในวิธีการและมอบสิทธิ์ให้กับแอปพลิเคชัน ชอบ:

   EntityManager.save (นิติบุคคล);

2. บริการบางอย่างเรียกฟังก์ชันฐานข้อมูล (ผ่านพารามิเตอร์) ไลค์:

   CallableStatement cls = con.prepareCall ("{เรียก databaseFunction (args)}");

3. บริการบางอย่างมีวิธีการที่มีทั้งพฤติกรรม

คำถามของฉัน:

1. มีปัญหาในการรับสายบริการโดยตรงหรือไม่ - ฟังก์ชั่นฐานข้อมูล? นี่ถือว่าเป็นการกระทำที่ไม่ดีหรือไม่? แบบจำลองสถาปัตยกรรมจะใช้กับโครงการเช่นนี้ได้อย่างไร
2. มีปัญหาใดบ้างหรือไม่ที่มีการผสมผสานพฤติกรรมในบริการเดียวกัน เช่นการทำธุรกรรมและความสอดคล้อง?
3. ในกรณีของการบำรุงรักษาการห่อหุ้มนี้ทำให้ผู้พัฒนาไม่ชัดเจนว่าเขาควรเปลี่ยนฟังก์ชั่นในฐานข้อมูลหรือไม่? จะหลีกเลี่ยงสิ่งนี้ได้อย่างไร
4. สถานการณ์นี้เกิดขึ้นในแอปพลิเคชันอื่น ๆ ทั่วโลกหรือเป็นเพียงข้อผิดพลาดทางสถาปัตยกรรมหรือไม่?

มีปัญหาในการรับสายบริการโดยตรงหรือไม่ - ฟังก์ชั่นฐานข้อมูล? นี่ถือว่าเป็นการกระทำที่ไม่ดีหรือไม่?

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

แบบจำลองสถาปัตยกรรมจะใช้กับโครงการเช่นนี้ได้อย่างไร

ดูความคิดเห็นด้านล่าง

มีปัญหาใดบ้างหรือไม่ที่มีการผสมผสานพฤติกรรมในบริการเดียวกัน เช่นการทำธุรกรรมและความสอดคล้อง?

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

ในกรณีของการบำรุงรักษาการห่อหุ้มนี้ทำให้ผู้พัฒนาไม่ชัดเจนว่าเขาควรเปลี่ยนฟังก์ชั่นในฐานข้อมูลหรือไม่?

แน่นอนมันทำ

จะหลีกเลี่ยงสิ่งนี้ได้อย่างไร

วางวิธีการและฟังก์ชั่นที่ทำงานโดยตรงกับฐานข้อมูลในระดับที่แยกจากกันของนามธรรม (ไม่ว่าจะเป็นเลเยอร์ DAO หรือรูปแบบพื้นที่เก็บข้อมูลที่เรียบง่าย - ขึ้นอยู่กับความซับซ้อนของแอปพลิเคชันของคุณ)

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

ฉันคิดว่าในโลกของเราทุกอย่างเกิดขึ้น;)

ตามที่คุณพูดมีชั้นบริการเพื่อให้รูปแบบสถาปัตยกรรมที่ดูเหมือนเหมาะสมคือเลเยอร์สถาปัตยกรรม อ้างอิงเพิ่มเติม

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

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

ข้อดีของการใช้รูปแบบการออกแบบและ ORM คือความสามารถในการอ่านรหัสของคุณในการห่อหุ้มความรับผิดชอบดังนั้นหากการเข้าถึงฐานข้อมูลของคุณเปลี่ยนเลเยอร์ธุรกิจของคุณไม่ควรเปลี่ยนแปลงมากนัก