>> บางทีเราก็กำลังทำแบบนั้นอยู่ แต่เราอาจไม่รู้ตัวว่าทำแบบนั้นอยู่ก็ได้
งั้นเอาตัวอย่างนี้

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

N tier แน่นอน

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

อันนี้ตามความเข้าใจผมนะ ลืมไปแล้วว่าเรียนอะไรมา

1. N-tier เป็นรูปแบบเฉพาะของพวก component-based ทั้งหลายซึ่งแทนที่จะกระจายตามสะดวกก็มีการวางโครงสร้างให้เป็นชั้นๆ
2. การติดต่อระหว่างชั้นจะทำได้เฉพาะชั้นติดกันเท่านั้น

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

1. ผอ.ไม่เคยสนว่าจะมีเอกสารการเงินมากแค่ไหน ทำงานยังไง มี ERP หรือเปล่า ขอแค่ฝ่ายการเงินทำรายงานประจำเดือนมาให้ก็พอ
2. ฝ่ายการเงินทำงานเอกสารโขยงนึง แต่จริงๆ แล้วไม่ได้เก็บเอง ERP ทำให้เกือบหมด รายงานทั้งหลายก็เป็น ERP ทำมา แต่ต้องผ่านการตรวจทานและสรุปจากฝ่ายการเงินเสียก่อน
3. ERP ไม่รู้อะไรทั้งนั้น เก็บๆ พิมพ์

วันดีคืนดีเปลี่ยนฝ่ายการเงินยกชุด ชุดใหม่ใช้ ERP เป็น คุยกับผอ.รู้เรื่องก็จบ หรือเปลี่ยนผอ. คนใหม่ก็คุยกับการเงินรู้เรื่องก็จบอีก หรือจะเปลี่ยน ERP แต่วิธีใช้เหมือนเดิมก็จบ

ผมมองโลกในแง่ดีเกินไปรึเปล่าหว่า ไม่เคยเจอแบบนี้มาก่อน

เล่าจากที่ทำอยู่แล้วกันนะ
งานปัจจุบันส่วนใหญ่ผมจะ implement แยก module เป็น 3 ส่วน
1. Data access Layer, code ในส่วนนี้ ประกอบด้วย CRUD operation + Query ทั้งหลาย
2. Business Logic Layer, พวกกฎเกณฑ์ทางธุรกิจจะอยู่ที่นี่หมด เช่น ถ้าจ่ายเงินช้า ต้องคำนวณค่าปรับ
สูตรค่าปรับต้องคิดจากไหน อย่างไร, หรือการเก็บข้อมูลใบเสร็จรับเงิน ต้องไปตัดรายการใบแจ้งหนี้ด้วย
3. Presentation Layer, อันนี้ตรงตามชื่อ

คำถามที่ตามมาก็คือ "แบ่งอย่างนี้ แล้วรู้สึกว่ามันได้ประโยชน์อะไรไหม"
1. ที่ได้ประโยชน์ชัดสุดสำหรับผม ก็คือการแบ่งระหว่าง 2 กับ 3
ประโยชน์ที่ได้ไม่ใช่ในแง่ "โปรแกรมสามารถปรับเปลี่ยน presentation ได้ทันที โดยไม่ต้องยุ่ง business logic"
แต่เป็นในแง่ การแบ่งงานกันทำ เพราะช่องระหว่าง Business logic กับ Presentation Layer
มันเป็นรอยต่อที่ define ได้ชัดเจนดี คือสามารถเริ่มด้วยการออกแบบ interface กับ domain model ร่วมกัน
จากนั้นต่างคน ก็ต่างแยกย้ายไปทำในส่วนของตัวเอง
ทืม UI อาจจะทำ service หลอกๆ ขึ้นมาก่อน เพื่อที่จะ test หน้าจอของตัวเอง
พอทืม business logic ทำเสร็จ ก็แค่ switch เปลี่ยน code แค่บรรทัดเดียว
2. ส่วนในข้อ 1 มีก็ดี ไม่มีก็ไม่รุ้สึกอะไรมาก
ข้อดี สำหรับผม ก็คือปกติผมพัฒนาบน Database Postgres
แต่เวลา deploy ให้ลูกค้า ส่วนใหญ่จะเป็น DB2
มี Layer นี้ ก็ดีตรง switch database ง่ายดี

ิีbusiness logic layer บางเล่มก็เขียนว่ามันเรียกได้อีกอย่าวว่า application logic layer ชื่อก็ตามนั้นคือไว้ประมวลข้อมูลแล้ว

ถ้าเราแบ่วตาม app ที่เราใช้ได้ก็เป็น
Database layer --- MySql, Oracle, DB2, MSSQL, etc.
Business (Application) logic Layer --- JBOSS, websphere, weblogic
Presentation Layer --- apache, IIS

มั้ง

พอได้อ่านแล้ว พอจะเห็นภาพขึ้นมาบ้าง โดยส่วนตัวแล้ว ผมทำเว็บที่ติดต่อกับดาต้าเบส ก็แค่ insert delete update database แล้วก็ คิวรี่ แสดงผลออกทาง html เวลาเขียนโค๊ดผมก็จะชอบเขียนเป็น ฟังก์ชั่นแล้วก็เรียกกันไป เรียกกันมา แม้กระทั่งให้แสดงผลออกมาเป็นตาราง ผมก็จะเขียนเป็นฟังก์ชั่น คือผมมองว่ามันสะดวกดี ที่เราไม่ต้องตั้งชื่อตัวแปรให้มันมาก แล้วผมก็เอาฟังก์ชั่นเกือบทั้งหมดเก็บลงในไฟล์ๆหนึ่ง แล้วก็ทำการดึงไฟล์นั้นเข้ามาใช้ ผมไม่ค่อยได้แยกว่าไฟล์นี้เก็บฟังก์ชั่นแสดงผลนะ ไฟล์นี้เก็บฟังชั่นจัดการกับดาต้าเบสนะ ทุกอย่างอยู่ในไฟล์เดียวกัน แต่แยกกันคนละฟังชั้น เพราะเวลาเปิดดูใน folder ดูเหมือนมันน้อยดี ไม่ต้องเปิดหลายไฟล์ ไม่ทราบว่าผมทำถูกไหม เพราะไม่ได้จบมาทางนี้ แต่บังเอิญว่าพอเขียนได้หน่ะครับ ฝากช่วยแนะนำหน่อย ว่าจริงๆแล้วต้องทำยังงัย ผมอยากทราบจริงๆ ขอบคุณครับ