Tổ chức mã ứng dụng nhiều Zend


10

Trong năm qua tôi đã làm việc trên một loạt các ứng dụng dựa trên khung Zend và tập trung vào logic kinh doanh phức tạp mà tất cả các ứng dụng phải có quyền truy cập ngay cả khi chúng không sử dụng tất cả (dễ dàng hơn là có nhiều thư mục thư viện cho mỗi ứng dụng ứng dụng vì tất cả chúng được liên kết với nhau với một trung tâm chung).

Không đi sâu vào chi tiết về những gì dự án cụ thể, tôi đang tìm kiếm một số đầu vào (vì tôi đang làm việc với dự án một mình) về cách tôi đã "nhóm" mã của mình. Tôi đã cố gắng phân chia tất cả theo cách mà nó loại bỏ sự phụ thuộc càng nhiều càng tốt.

Tôi đang cố gắng giữ nó tách rời như tôi có thể, vì vậy trong 12 tháng khi thời gian của tôi hết, bất kỳ ai khác đến cũng không gặp vấn đề gì với những gì tôi đã sản xuất.

Cấu trúc ví dụ:

applicationStorage\ (contains all applications and associated data)
applicationStorage\Applications\ (contains the applications themselves)

applicationStorage\Applications\external\ (application grouping folder) (contains all external customer access applications)
applicationStorage\Applications\external\site\ (main external customer access application)
applicationStorage\Applications\external\site\Modules\ 
applicationStorage\Applications\external\site\Config\
applicationStorage\Applications\external\site\Layouts\
applicationStorage\Applications\external\site\ZendExtended\ (contains extended Zend classes specific to this application example: ZendExtended_Controller_Action extends zend_controller_Action )
applicationStorage\Applications\external\mobile\ (mobile external customer access application different workflow limited capabilities compared to full site version)

applicationStorage\Applications\internal\ (application grouping folder) (contains all internal company applications)
applicationStorage\Applications\internal\site\ (main internal application)
applicationStorage\Applications\internal\mobile\ (mobile access has different flow and limited abilities compared to main site version)

applicationStorage\Tests\ (contains PHP unit tests)

applicationStorage\Library\
applicationStorage\Library\Service\ (contains all business logic, services and servicelocator; these are completely decoupled from Zend framework and rely on models' interfaces)
applicationStorage\Library\Zend\ (Zend framework)
applicationStorage\Library\Models\ (doesn't know services but is linked to Zend framework for DB operations; contains model interfaces and model datamappers for all business objects; examples include Iorder/IorderMapper, Iworksheet/IWorksheetMapper, Icustomer/IcustomerMapper)

(Lưu ý: các thư mục Mô-đun, Cấu hình, Bố cục và ZendExtends được sao chép trong mỗi thư mục ứng dụng; nhưng tôi đã bỏ qua chúng vì chúng không bắt buộc cho mục đích của tôi.)

Đối với thư viện này chứa tất cả mã "phổ quát". Khung công tác Zend là trung tâm của tất cả các ứng dụng, nhưng tôi muốn logic kinh doanh của mình độc lập với khung công tác. Tất cả các giao diện mô hình và trình ánh xạ không có tham chiếu công khai đến Zend_Db nhưng thực sự bao quanh nó ở chế độ riêng tư.

Vì vậy, hy vọng của tôi là trong tương lai tôi sẽ có thể viết lại các trình ánh xạ và dbtables (chứa Mô hình_DbTable_Abauge mở rộng Zend_Db_Table_Ab khu vực) để tách logic logic kinh doanh của tôi khỏi khung công tác Zend nếu tôi muốn chuyển logic kinh doanh của mình sang dịch vụ môi trường khung không Zend (có thể một số khung PHP khác).

Sử dụng một dịch vụLocator và đăng ký các dịch vụ cần thiết trong bootstrap của mỗi ứng dụng, tôi có thể sử dụng các phiên bản khác nhau của cùng một dịch vụ tùy thuộc vào yêu cầu và ứng dụng nào đang được truy cập.

Ví dụ: tất cả các ứng dụng bên ngoài sẽ có dịch vụ_auth_External triển khai dịch vụ_auth_Interface đã đăng ký.

Tương tự với các ứng dụng nội bộ với Service_Auth_Ialal triển khai dịch vụ_auth_Interface Service_Locator :: getService ('Auth').

Tôi lo ngại tôi có thể thiếu một số vấn đề có thể xảy ra với điều này.

Tôi nghĩ một nửa là một tệp config.ini cho tất cả các phần bên ngoài, sau đó là một ứng dụng riêng biệt config.ini ghi đè hoặc thêm vào tệp config.ini bên ngoài toàn cầu.

Nếu ai có bất cứ đề nghị nào tôi sẽ rất cảm kích.

Tôi đã sử dụng bối cảnh chuyển đổi cho các chức năng AJAX trong các ứng dụng riêng lẻ, nhưng có khả năng lớn cả bên ngoài và bên trong sẽ có các dịch vụ web được tạo cho chúng. Một lần nữa, những điều này sẽ được tách ra do ủy quyền và các dịch vụ có sẵn khác nhau.

\applicationstorage\Applications\internal\webservice 
\applicationstorage\Applications\external\webservice

Câu trả lời:


1

Cuối cùng, một số mã sẽ dành riêng cho "logic kinh doanh" của ứng dụng của bạn và một số là "mã thư viện". Ví dụ: một cái gì đó xác nhận đầu vào biểu mẫu thường có thể được coi là "thư viện", trong khi thứ gì đó giúp bạn tính toán các ưu đãi có sẵn cho khách hàng X trong một tháng nhất định rõ ràng là "logic kinh doanh".

Đây là vấn đề kiểm soát phiên bản nhiều hơn, và có nhiều cách bạn có thể lột da con mèo đặc biệt này. Các công cụ như Maven (và ở một mức độ nào đó Phing / Ant) được xây dựng để lắp ráp các ứng dụng từ nhiều nguồn khác nhau - dựa trên một số loại tệp cấu hình bên ngoài (nói chung là XML). Điều này có nghĩa là bạn có thể duy trì các repos riêng cho mã thư viện và nhập nó vào Ứng dụng X nếu bạn cần.

Nếu bạn có quyền kiểm soát máy chủ của mình, thì bạn có thể nghĩ về việc chuyển nội dung thư viện vào đường dẫn bao gồm - và duy trì điều đó như một dự án dài hạn riêng biệt.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.