2010-09-18 32 views
25

Tôi đang theo một hướng dẫn mà tôi nghĩ là được viết bởi một người không biết những gì anh ấy đang làm (đã bắt được 2 lỗi rõ ràng và phần còn lại của mã là lộn xộn). Nhưng tôi không muốn làm mất uy tín anh chàng hoàn toàn, vì vậy tôi hỏi ở đây về một thứ khác mà tôi không hiểu.Mã này có phát điên không?

Trước hết, tôi sẽ gửi 100 điểm đên, 2 thú cưng của tôi, và một hộp sô cô la để bất cứ ai có thể giải thích cho tôi những gì là xảy ra với mã này.

Anh ấy đang sử dụng kiến ​​trúc dựa trên mô-đun. Tên mô-đun là frontmodule. Module có MVC. Và mô-đun có một nội bộ của riêng mình là library.

/modules/  
     /frontmodule/ 
      /models/ 
      /views/ 
      /controllers/  -- the /module controller is here (undestandable) 
      /library/    
      /Controller/  -- the /module/library controller is here (why?!) 
       /Action/ 

Đầu tiên là gây nhầm lẫn một phần. Tại sao mỗi mô-đun có thư viện nội bộ và tại sao thư viện nội bộ đó lại có controllersactions riêng. Đây có phải là phương pháp hay nhất không? Tôi nghĩ thư viện này có thể được chuyển đến một plugin mà module có thể sử dụng. Bạn không chắc chắn ..

Bây giờ đến thú phần .... ngoài mỗi module có thư viện nội bộ riêng của mình, cũng có một thư viện chung được chia sẻ bởi tất cả các module (xem dưới đây ở cấp thư mục giống như /modules) và thư viện chung cũng có bộ điều khiển và hành động (giống như mỗi thư viện nội bộ riêng của mình có bộ điều khiển riêng của họ và hành động)

/modules 
    /library/ 
     /Common/ 
      /Controller/   -- the /common/library controller is here (why?!) 
       /Action/ 
        /Helper/ 
       /Plugin/ 

Vì vậy, chúng tôi có 3 điều khiển:

  • module điều khiển
  • điều khiển thư viện nội bộ của mô-đun
  • điều khiển thư viện chung của

Bây giờ đây là điên phần mà tôi nghĩ là quá phức tạp cuộc sống

Anh ấy nói: A mo bộ điều khiển dule mở rộng bộ điều khiển cha mẹ của thư viện của mô-đun cũng mở rộng thư viện Common bộ điều khiển.

class IndexController 
     extends Frontoffice_Library_Controller_Action_Abstract { ... } 

abstract class Frontoffice_Library_Controller_Action_Abstract 
     extends Custom_Controller_Action_Abstract { ... } 

Vì vậy, tôi đoán:

  • bộ điều khiển mô-đun = IndexController
  • điều khiển mô-đun nội bộ thư viện của = Frontoffice_Library_Controller_Action_Abstract
  • điều khiển thư viện chung của = Custom_Controller_Action_Abstract

nơi module controller kéo dài module internal library's controller

module internal library's controller kéo dài common library's controller

Có ai nhìn thấy bất cứ điều gì như thế này trước đây chưa? Tôi đoán là mã này sẽ không dễ dàng để duy trì, nhưng có lẽ những người có kinh nghiệm hơn với zend có thể cho tôi biết anh chàng này đang cố gắng đạt được điều gì. Cấu trúc ứng dụng hơi lộn xộn một chút. Tôi nghĩ anh ta lạm dụng MVC thay vì sử dụng nó để đơn giản hóa ứng dụng và khả năng bảo trì của nó.

+4

Lol ... Ồ, tôi cần thiết đó. Cảm ơn! –

+6

Anh ấy chỉ muốn làm cho cuộc sống của bạn trở nên khó khăn hơn. – netrox

+0

@netrox, Xem Tôi không chắc chắn. Có thể có một cái gì đó về nó mà tôi không nhận được. Đây là lý do tại sao tôi chờ đợi để nghe từ những người có nhiều kinh nghiệm trong khuôn khổ zend, mặc dù tôi hy vọng bạn có thể đúng, và rằng nó 'quá kỹ thuật' như beamrider9 nói – jblue

Trả lời

16

Điều tuyệt vời về khung công tác Zend là sử dụng theo ý muốn có nghĩa là bạn có thể sử dụng một thành phần đơn lẻ hoặc bạn có thể sử dụng tất cả. Hầu hết các thành phần cũng rất linh hoạt hoặc thông qua cấu hình hoặc mở rộng (thừa kế hoặc thành phần, với ZF ưu tiên sau này).

Zend Framework MVC là cực kỳ linh hoạt ... thậm chí đến mức mà nhiều người đã cáo buộc nó là quá chế tạo hoặc cồng kềnh chính nó. Đây là chủ quan.

Chắc chắn, bạn có thể sẽ không muốn sử dụng Zend Framework cho một biểu mẫu liên hệ đơn giản; tuy nhiên, không có gì ngăn cản bạn sử dụng Zend_Mail và Zend_Form mà không có Zend MVC/Application.Với sự linh hoạt trong tâm trí, hiện tại không có phương pháp duy nhất nào được chào hàng là tốt nhất trong việc tổ chức một ứng dụng thành các mô-đun. Đây là một công việc tốt nhất còn lại cho người thực hiện.

Điều này đưa chúng ta đến hướng dẫn trong tầm tay. Các nhà văn hướng dẫn đã đưa ra một chiến lược để tái sử dụng. Đây là một điều tốt; tuy nhiên, có một số sai sót với cách tiếp cận của anh ta.

  1. Thư viện trên mỗi mô-đun. Điều này không nhất thiết là xấu; tuy nhiên, trong hầu hết các trường hợp không cần thiết. Cho phép khám phá những tùy chọn chúng ta có chỉ trong trường hợp một cấu trúc như vậy cần thiết cho một số lý do.

    a. Xây dựng một thư viện chung (bạn rất có thể đã làm điều này) không gian tên (giả nếu < 5.3 hoặc không gian tên thực tế nếu> = 5.3).

    b. Sử dụng "Tự động tải tài nguyên" nội bộ http://framework.zend.com/manual/en/zend.loader.autoloader-resource.html

    LƯU Ý: Cá nhân tôi chưa sử dụng tự động tải nhiều tài nguyên. Một lần mà tôi đã sử dụng nó, tôi thấy rằng tôi có thể vừa chuyển những thứ đó vào thư viện của tôi. Điều đó đang được nói, có sử dụng cho việc này. Nó dường như tỏa sáng khi bạn mong đợi để trộn và kết hợp các mô-đun trên các dự án hoặc để phân phối. ZF2 sẽ giải quyết vấn đề này theo cách ít hack hơn IMHO.

  2. Bộ điều khiển cơ sở để sử dụng lại. Một lần nữa, tái sử dụng là rất tốt; tuy nhiên, Zend Framework cung cấp các lựa chọn thay thế tốt hơn cho các bộ điều khiển lớp con (kế thừa). Trước tiên, dưới đây là một số lý do KHÔNG sử dụng quyền thừa kế của bộ điều khiển:

    a. Giữ mọi thứ DRY bị đánh bại khi bạn có nhiều mô-đun đủ khác nhau để cần một lớp cơ sở cho mỗi mô-đun nhưng chức năng được sao chép/dán trên mỗi lớp bộ điều khiển cơ sở của mô-đun.

    b. Việc quản lý các thuộc tính được thừa kế trở nên khó khăn vì khó hình dung được chức năng được thừa hưởng nào đang được sử dụng bởi mỗi bộ điều khiển/hành động

    c. Với PHP cho phép thừa kế lớp chỉ duy nhất, bạn thổi một cơ hội của bạn tại đây thừa kế - sử dụng này nếu không có lựa chọn khác trái

    Alternatives:

    một. Plug-in Front-Controller Sử dụng các chức năng này khi chức năng/logic cần chạy trên mọi yêu cầu bất kể module/controller/action

    b. Người trợ giúp hành động Như đã đề cập trong dự án ZF, "Chúng là một cơ chế tích hợp trong Zend Framework cho phép bạn mở rộng bộ điều khiển hành động theo cách sử dụng bố cục thay vì thừa kế". Không có bất cứ điều gì mà bạn có thể làm trong bộ điều khiển mà bạn không thể thực hiện thông qua trình trợ giúp hành động. Sử dụng các chức năng này khi chức năng cần phải xảy ra trên mỗi bộ điều khiển và/hoặc hành động.

Vì vậy, ví dụ trong hướng dẫn được thiết kế quá mức? Không nhất thiết phải; tuy nhiên, nó chắc chắn là một ứng cử viên cho được thiết kế không chính xác vì nó liên quan đến các thực tiễn tốt nhất và các điều khoản do Zend Framework đưa ra.

tôi cần phải lạc đề một chút và thảo luận về các điều khoản qua chếcồng kềnh cho chỉ là một khoảnh khắc

Khi ai đó nói với bạn rằng một cái gì đó là qua chế và/hoặc bloated mà không nêu rõ một bối cảnh xin vui lòng mang nó với một hạt muối.

Bài viết trên Wikipedia - http://en.wikipedia.org/wiki/Overengineering đọc một phần "... khi một sản phẩm mạnh mẽ hơn hoặc phức tạp hơn mức cần thiết cho ứng dụng ..." của chúng tôi.

Vì vậy, khi đề cập đến một cái gì đó như Over chế/một cồng kềnh nên cẩn thận để đủ điều kiện bối cảnh hoặc ứng dụng trong tầm tay. Tuyên bố chăn nên được thực hiện với một hạt muối và trong hầu hết các trường hợp, không được thực hiện ở tất cả. Điều này cũng giống như nói "Tôi không bao giờ sử dụng 'cưa tròn' để chế biến gỗ vì nó có quá nhiều tính năng và những tính năng này làm tôi bối rối". Chắc chắn, công cụ này có thể bị giết quá mức đối với các dự án nhà/bên nhỏ; tuy nhiên, vì nó là siêu linh hoạt, bạn sẽ rất vui khi bạn có công cụ này khi bạn thấy mình trong những tình huống mà bạn chưa bao giờ nghĩ mình sẽ tìm thấy chính mình.

Có, nhất khuôn khổ web bị giết quá mức cho một ứng dụng CRUD đơn giản như trang liên hệ hoặc thậm chí là ứng dụng viết blog đơn giản. Thật không may là hầu hết các khung công tác web đều sử dụng ví dụ về blog làm ví dụ giới thiệu của họ - con số đi.

tắm Info:

  1. Nếu bạn muốn chuyển đổi bố trí dựa trên các module/controller/action, bạn có thể viết một Front-điều khiển Plug-in. Chỉ cần gọi "Zend_Layout :: startMvc" và chuyển cho nó tên bố cục và đường dẫn.

  2. Switching kịch bản xem thực tế căn cứ vào Chấp nhận tiêu đề (hoặc tham số URL hoặc X-HTTP-PHƯƠNG PHÁP-ghi đè lên phần đầu) có thể được thực hiện với sự giúp đỡ bối cảnh chuyển đổi hành động (nội tại để Zend Framework) - http://framework.zend.com/manual/en/zend.controller.actionhelpers.html

  3. Hãy thoải mái chuyển một thể hiện mô hình đến một trình trợ giúp hành động. Bạn cũng có thể cấu hình người trợ giúp hành động của bạn với cấu hình từ bootstrap. Bằng cách này, không cần phải lưu trữ mọi thứ trong sổ đăng ký toàn cục, đó chỉ là một biến toàn cầu được vinh danh. Đây là một phụ thuộc ẩn mà bạn không cần.Đối với sử dụng lại tốt nhất, bạn có thể tạo riêng plug-in nguồn tùy chỉnh của bạn bằng cách mở rộng Zend_Application_Resource_ResourceAbstract - http://framework.zend.com/manual/en/zend.application.core-functionality.html#zend.application.core-functionality.resource-resourceabstract

15

Điều này thật điên rồ. Bạn đang tạo trang web, đúng không? Điều này không khó. Tôi muốn nói những thứ bạn được đăng là định nghĩa rất của overengineering:

http://en.wikipedia.org/wiki/Overengineering

+3

Nó không thực sự được thiết kế quá mức, nó được thiết kế không chính xác theo các phương pháp hay nhất của Zend Framework. –

+1

Như bạn đã nói, đó là khá chủ quan. Một số - bản thân tôi được đưa vào - sẽ cho rằng khung công tác Zend (giống như hầu hết các khung công tác web) chính là một ví dụ điển hình về việc quá tải. –

+1

là một người đã thực hiện nó theo cách cũ với tệp .php trên mỗi trang cho các độ tuổi, tôi có thể nói rằng tôi chắc chắn đã nghĩ theo cùng một cách khi tôi lần đầu tiên bắt đầu với nó. Đó là một sự thay đổi mô hình ban đầu, nhưng một khi bạn vượt qua rào cản đó tại sao tôi cần phải tách mã của tôi thành logic/views/etc, bạn bắt đầu trải nghiệm vẻ đẹp của Zend (không chỉ Zend, mà là kiến ​​trúc MVC nói chung. không phát minh ra MVC, nó chỉ sử dụng nó). Vì vậy, tôi muốn nói cho zend hoặc bất kỳ khuôn khổ MVC khác một thử. Zend xảy ra để được duy trì bởi công ty giám sát PHP nên chắc chắn một trong những điều được duy trì tốt hơn – jblue

10

Không điên chút nào. Có lẽ thiết kế quá tệ hoặc quá mức, nhưng nó có thể là một thiết lập hữu ích.

Nó chỉ là hai cấp thừa "thừa", mà trong một số trường hợp có thể có ý nghĩa hoàn hảo.

  • thuộc tính hoặc phương pháp sẽ có sẵn trong mọi bộ điều khiển trong hệ thống đi trong "bộ điều khiển thư viện chung".
  • tính hoặc các phương pháp đó phải được sẵn trong mỗi bộ điều khiển trong một module cụ thể đi trong "mô-đun điều khiển nội bộ thư viện của" -
  • tính hoặc các phương pháp theo yêu cầu của một duy nhất, điều khiển bê tông , sống trong rằng bê tông điều khiển.

Nhưng nói chung, điều này cho thấy đóng gói một lô khủng khiếp của logic vào bộ điều khiển, thường là thiết kế tồi.

+1

+1 nhưng chúng ta hãy nói về 'các thuộc tính hoặc phương thức này sẽ có sẵn trong mọi bộ điều khiển trong hệ thống đi vào "bộ điều khiển thư viện chung" .' Tại sao xác định một "thư viện chung với bộ điều khiển" khi bạn có thể sử dụng 'application/controller 'ở cấp ứng dụng? Bạn nói nó có lẽ là 'có lẽ quá tệ hoặc quá chế tạo' .. Có phải đây là cách tốt hơn để làm điều tương tự không? – jblue

+0

@jblue - Ứng dụng/điều khiển' là gì? Trong hầu hết các thiết lập ZF tôi đã thấy, bạn có một thư mục có tên là 'application/controllers' chứa các bộ điều khiển cơ bản là controller của module mặc định, mặc dù trong một số thiết lập module, không có gì ở đó, và có một module có tên' mặc định'. – timdev

+0

@jblue - như cách tốt hơn để làm công cụ này, nó phụ thuộc vào những gì bạn đang làm. Trong hầu hết các trường hợp, công cụ cần chia sẻ giữa các bộ điều khiển khác nhau sẽ tốt hơn trong "mô hình" (tuy nhiên bạn xác định nó trong ứng dụng của mình) hoặc trong một số loại plugin tài nguyên. – timdev

0

Bằng cách này, bạn có thể có logic áp dụng cho:

a) một bộ điều khiển đặc biệt

b) tất cả các bộ điều khiển trong một module

c) tất cả các bộ điều khiển ứng dụng

Các vấn đề liên quan