Tôi đã có một ứng dụng MVC được viết bằng Zend Framework để lấy dữ liệu từ cơ sở dữ liệu Oracle 10g và hiển thị dữ liệu này trong Bảng và Danh sách và làm phong phú thêm dữ liệu này thông qua màu sắc và biểu đồ. Không có ORM và không tạo, cập nhật hoặc xóa liên quan, chỉ đọc thuần túy. Dữ liệu được chèn từ một ứng dụng khác. Dữ liệu trong DB được mô hình hóa sau khi các khái niệm mà chúng đại diện và truy cập bởi Chế độ xem DB tổng hợp dữ liệu này từ các bảng khác nhau (kế thừa, không thể thay đổi), ví dụ:Bạn sẽ mô hình hóa ứng dụng này như thế nào?
| Event ID | Start | End | Status | Created_By |
-----------------------------------------------------------------------------
| 12345678 | 2009-10-01 12:00:00 | 2009-10-01 12:15:00 | booked | John Doe |
| 12345679 | 2009-11-01 13:00:00 | 2009-12-01 12:00:00 | booked | John Doe |
| 12345680 | 2009-11-01 13:00:00 | 2009-12-01 12:00:00 | tba | Jane Doe |
Người dùng có thể ảnh hưởng đến hiển thị cột, sắp xếp và sắp xếp từ Chế độ xem. Khách hàng có thể từ chối/cho phép truy cập vào các cột và giới hạn nội dung cột thành các giá trị nhất định. Người dùng không thể ghi đè cài đặt ứng dụng khách. Một người dùng là một diễn viên, trong khi một khách hàng về cơ bản chỉ là một bộ lọc tạo ra một tập con của dữ liệu sẵn có cho một người dùng thuộc về máy khách. Cài đặt người dùng và ứng dụng khách được duy trì.
cách tiếp cận hiện tại của tôi làm việc gần như thế này:
Request --> Controller
| <--> sanitizes and returns Request params
| ---> Facade (capsules steps to fetch View Data)
| | <--> Table Data Gateway builds Query for requested View
| | <--> Query Decorator¹ applies User/Client settings
| | <--> DB Adapter fetches RecordSet from decorated Query
| <----returns Recordset
| <--> applies RecordSet to View
| <--> Data-Aware ViewHelper render RecordSet (and View)
Response <--returns rendered View
¹Các Query Decorator có thể đọc trong thư mục/Cài đặt khách hàng tài khoản tiếp tục tồn tại và thêm nó vào các đối tượng truy vấn cơ bản được trả về bởi các TDG khi đang bay.
Tuy nhiên, gần đây tôi đã nghi ngờ cách tiếp cận này và muốn cải thiện nó. Tôi đoán tôi có thể loại bỏ hoàn toàn TDG và làm cho tòa nhà View hoàn toàn giống với giao diện người dùng; chỉ dựa trên cấu trúc DB. Người dùng chắc chắn sẽ thích điều này. Vấn đề là, View phải biết rất nhiều về dữ liệu. Các ViewHelpers phải biết tên cột để làm giàu dữ liệu và thường họ làm như vậy liên quan đến nhiều cột trong Recordsets. Họ không thể là chung chung và một cái gì đó nói với tôi điều này là rắc rối anyway. Nó cảm thấy như mishmash. Tôi chỉ không thể xác định tại sao.
Bất kỳ mẫu, ý tưởng - và ý kiến nào - được đánh giá cao. Tôi biết câu hỏi có phần mơ hồ, nhưng như tôi đã nói, tôi không thể xác định điều gì khiến tôi nghi ngờ cách tiếp cận này. Vì vậy, tôi đoán tôi đang tìm kiếm bất kỳ phương pháp tiếp cận thực hành tốt để xây dựng ứng dụng trung tâm cơ sở dữ liệu tùy biến người dùng và khách hàng một cách duy trì. Tôi chắc chắn không cần một giải pháp, chỉ cần một số ý tưởng và có thể là một vài liên kết để xem cách những người khác tiếp cận vấn đề này, vì vậy tôi có thể đưa nó vào tài khoản về việc tái cấu trúc tiếp theo.
Lưu ý
Tôi sẽ để câu hỏi mở trong suốt thời gian trước khi chấp nhận câu trả lời. Bất kỳ đầu vào nào được đánh giá cao.
Hãy tha thứ cho sự hoài nghi của tôi, nhưng: Quan điểm cần biết nhiều về dữ liệu? Các ViewHelpers phải biết tên cột? * Tại sao? * Điều này gần giống như một hiệu ứng Inner-Platform, một sự sáng tạo của Microsoft Access hoặc Cognos. Tùy biến vượt quá một ngưỡng nhất định là điều ác; nó có thể là * yêu cầu * cần tái cấu trúc. – Aaronaught
@Aaronaught Skepticism là tốt. Đó là điều khiến tôi hỏi câu hỏi này :) Để trả lời câu hỏi của bạn: hãy tưởng tượng có một ViewHelper sẽ hiển thị thanh thời gian dựa trên * Start *, * End * và * Status * như một phần của bảng hiển thị toàn bộ Recordset ngoài ViewHelper biểu diễn một PieChart dựa trên * Created_By *. – Gordon