Bạn sử dụng mẫu thiết kế/mẫu thiết kế ứng dụng PHP nào?

Question

Hãy chia sẻ các mẫu thiết kế/mẫu thiết kế ứng dụng yêu thích của bạn để sử dụng trong PHP với tôi. Một số điều tôi muốn biết:

• Làm thế nào thư mục của bạn được thiết kế
• Làm thế nào bạn sử dụng đối tượng oritentation trong các ứng dụng PHP của bạn
• Bạn có một cách tiêu chuẩn để đối phó với CRUD, pagination, hoặc bất kỳ các nhiệm vụ phổ biến khác?
• Làm cách nào để tránh sử dụng mã lặp lại? Cách tiếp cận của bạn với thư viện/chia sẻ mã chung là gì?
• Những cách thức mà bạn có thể làm cho mã của mình thanh lịch hơn?

Bạn không phải trả lời tất cả những điều này, trả lời bất kỳ hoặc một vài trong số này sẽ hữu ích. Lý do tôi hỏi điều này, là vì tôi rất mệt mỏi khi viết mã lặp lại, xấu xí trong PHP và tôi muốn tạo một khung nhỏ cho các dự án tự do của mình, giúp lập trình dễ dàng hơn và để tôi tập trung vào thách thức/nhiệm vụ kinh doanh hơn là xác nhận mẫu, phân trang và các hoạt động trần tục khác chiếm 80% công việc lập trình trong PHP

Tất cả các ý kiến ​​đều được đánh giá cao!

Answer 1

tôi có thể được bình chọn xuống cho điều này, nhưng nếu bạn thực sự muốn viết khuôn khổ riêng của bạn, tôi nói đi cho nó vì bạn sẽ học được rất nhiều từ kinh nghiệm. Các khuôn khổ khác được đề cập ở đây là rất tốt và được thử nghiệm và bạn sẽ không đưa ra quyết định xấu bằng cách sử dụng chúng, nhưng đó là sự lựa chọn của bạn.

Trước khi bắt đầu viết khuôn khổ của bạn, hãy xem các khung công tác khác (theo cú pháp, cấu trúc thư mục, lược đồ đặt tên, mẫu thiết kế, v.v.) và tìm hiểu lý do tại sao họ đã làm những gì họ đã làm và sẽ làm khác đi. Hãy thử một vài hướng dẫn và chơi với mã của chúng, tạo một vài ứng dụng mẫu. Nếu, sau khi làm điều đó, bạn không thích sử dụng chúng, sau đó tiếp tục và bắt đầu lập kế hoạch khung của bạn, giữ những gì làm việc và cải thiện những gì không.

Nếu bạn quyết định để cuộn của riêng bạn, sau đây là một vài điều tôi muốn giới thiệu từ kinh nghiệm của riêng tôi:

• Hãy an ninh ưu tiên hàng đầu của bạn - Nếu bạn viết một lớp truy cập dữ liệu, sử dụng thông số bị ràng buộc. Nếu bạn viết một mẫu đơn , hãy bảo vệ chống lại CSRF và XSS. Nắm bắt ngoại lệ của bạn và xử lý các lỗi của bạn. Đảm bảo rằng môi trường PHP của bạn an toàn. Đừng cố gắng xuất hiện với thuật toán mã hóa của riêng bạn . Nếu bạn không tập trung về bảo mật, bạn không nên viết khung làm việc của riêng mình.
• Nhận xét Mã của bạn - Bạn sẽ cần nhận xét để giúp bạn nhớ cách mã của bạn hoạt động sau một thời gian. Tôi thường thấy rằng các nhận xét về tài liệu tham khảo là quá đủ. Ngoài ra, nhận xét lý do bạn đã làm điều gì đó, chứ không phải những gì bạn đã làm. Nếu bạn cần giải thích những gì, bạn có thể muốn cấu trúc lại.
• Lớp trách nhiệm duy nhất và Phương pháp - Hầu hết các lớp học của bạn và phương pháp nên làm một việc và chỉ một điều. Đặc biệt, hãy xem điều này với cơ sở dữ liệu - Lớp học phân trang của bạn không nên dựa vào đối tượng truy cập dữ liệu của bạn, cũng không nên hầu như bất kỳ lớp nào khác (cấp thấp).
• Unit Test - Nếu mỗi người trong số các phương pháp của bạn không chỉ có một điều, nó phải là xa dễ dàng hơn để kiểm tra chúng và nó sẽ kết quả trong mã tốt hơn.Viết bài kiểm tra trước, sau đó mã để vượt qua bài kiểm tra . Điều này cũng sẽ cung cấp cho bạn nhiều hơn quyền tự do để tái cấu trúc sau này mà không cần vi phạm điều gì đó.
• Tóm tắt Lớp học tương tự - Nếu bạn có nhiều hơn một lớp mà không những điều tương tự, tạo ra một lớp cha mẹ có sử dụng những điểm tương đồng giữa các lớp và mở rộng nó.
• đại biểu và modularize - Nếu bạn viết một hệ thống xác nhận (và rất có thể là bạn có lẽ sẽ), không bao gồm từng validator như một phương pháp trong một số siêu xác nhận lớp. Phân tách chúng thành từng lớp riêng lẻ và gọi chúng khi cần. Bạn có thể áp dụng này ở nhiều khu vực: bộ lọc, ngôn ngữ, thuật toán, trình xác thực, v.v.
• Bảo vệ và tư nhân hóa - Trong hầu hết các trường hợp , nó tốt hơn để sử dụng phương thức getter và setter thay vì cho phép truy cập trực tiếp đến các biến lớp.
• Phù hợp API - Nếu bạn có một render() phương pháp và phương pháp hòa() mà làm những điều tương tự trong lớp khác nhau, chọn một và đi với nó trên tất cả các lớp học. Giữ thứ tự của các tham số giống nhau cho các phương thức sử dụng cùng các tham số. API nhất quán là API dễ dàng hơn.
• Ghi tự động load - Lớp tên có thể nhận được một chút vụng về và dài, nhưng cách Zend tên các lớp và tổ chức các thư mục làm tự động load dễ dàng hơn nhiều. Cập nhật: Kể từ PHP 5.3, bạn nên bắt đầu sử dụng các không gian tên.
• Không bao giờ lặp lại hoặc in bất cứ điều gì - Tặng nó làm giá trị trả lại và cho phép người dùng quyết định xem có nên lặp lại hay không. Rất nhiều lần bạn sẽ sử dụng giá trị trả về làm thông số cho phương thức khác.
• Đừng cố gắng giải quyết các vấn đề của thế giới - Giải quyết vấn đề đầu tiên của riêng bạn. Nếu bạn không cần tính năng ngay bây giờ, như một lớp để bản địa hóa số hoặc ngày hoặc đơn vị tiền tệ, không viết. Đợi cho đến khi bạn cần.
• Không Preoptimize - Xây dựng một số các ứng dụng đơn giản với khung của bạn trước khi tinh chỉnh nó. Nếu không, bạn có thể dành nhiều thời gian không có gì hiệu quả.
• Sử dụng Nguồn Control - Nếu bạn dành không biết bao nhiêu giờ tạo ra một kiệt tác , không có nguy cơ nó bị mất.

Answer 2

Tôi gần như cảm thấy như một kỷ lục bị phá vỡ, nhưng tôi sẽ khuyên bạn nên có một cái nhìn tại một số các khuôn khổ chung vì hai lý do:

1. Thậm chí nếu bạn chọn không sử dụng một, một số trong số đó là được viết rất tốt và được thiết kế rất tốt. Tôi đặc biệt thích Zend Framework nhưng tôi sẽ quay trở lại điều đó trong một giây.
2. Tự hỏi tại sao bạn đang phát minh lại bánh xe. Bạn có thực sự cảm thấy rằng bạn hiểu cùng một vấn đề thiết kế mà mọi người khác phải đối mặt tốt hơn nhiều so với cộng đồng phía sau (chèn khung lựa chọn ở đây) để biện minh cho việc viết một cái gì đó từ đầu? Phát biểu như một người ban đầu nhìn vào một số khung và quyết định rằng chúng quá lớn, thể hiện quá nhiều đường cong học tập hoặc quá nhiều chi phí và do đó phát triển của riêng tôi, tôi có thể nói với bạn rằng viết của riêng bạn từ đầu là một nỗi đau lớn nếu bạn chỉ có thể sử dụng một cái hiện có có thể dễ dàng mở rộng.

Nói về việc sử dụng một khuôn khổ có thể dễ dàng mở rộng, tôi đã có những trải nghiệm rất tích cực với Khung công tác Zend. Đó là cấu trúc kết dính và không có kết cấu lỏng lẻo, có thể nhanh chóng và dễ dàng mở rộng bất kỳ thành phần hiện có nào và toàn bộ khuôn khổ được thiết kế xung quanh ý tưởng rằng bạn sẽ cần phải viết các lớp trợ giúp và plugin của riêng mình để thêm vào chức năng tổng thể của nó.

Tôi đã tìm thấy Zend Framework hoàn toàn linh hoạt đến mức tôi đang chạy một trang web như một phần của Zend Framework MVC và một phần framework cũ của tôi và thậm chí là mã crappier cũ hơn mà tôi chưa viết lại. Trong thực tế, bởi vì trong quá trình viết lại, chúng tôi đã tìm thấy một trang chạy không được chấp nhận chậm bằng cách sử dụng khung cũ, tôi đã chuyển sang một trang duy nhất để chạy trong kiến ​​trúc khung công tác Zend.

Để trả lời một số câu hỏi của bạn, tôi khuyên bạn nên xem xét các mẫu Kiến trúc ứng dụng doanh nghiệp của Martin Fowler. Ông cung cấp nhiều thông tin chi tiết có giá trị về cách giải quyết một số vấn đề phổ biến như cách tạo lớp tương tác cơ sở dữ liệu trong ứng dụng của bạn. Fowler cũng bao gồm các chủ đề như MVC và Front Page Controller.

Answer 3

Tôi đã giải thích hầu hết phương pháp PHP của mình here.

nhưng hiện tại, tôi chỉ sử dụng Django ở mọi nơi tôi có thể.

Answer 4

Tôi bắt đầu với công cụ tạo mẫu smarty khi lần đầu tiên tôi thấy mệt khi trộn mã và html. Sau khi hack một thời gian, tôi nhận ra rằng việc viết framework của riêng tôi chỉ là việc sao chép.

Tôi đã thực hiện một vài dự án với Joomla, thực sự là một CMS nhưng nó mang lại cho khách hàng nhiều quyền kiểm soát nội dung.

Cuối cùng tôi đã quyết định sử dụng khung thực sự cho các dự án của mình. Tôi đang sử dụng symfony, được lấy cảm hứng từ Rails và được tài liệu rất tốt, nhưng tôi đã nghe cakePHP và ZendFramework cũng rất tốt.

Answer 5

Tôi phải đồng ý với các áp phích ở trên. Nếu bạn không sử dụng một khuôn khổ khi lập trình trong PHP, bạn thực sự lập trình với hai bàn tay của bạn được gắn sau lưng bạn. Cá nhân tôi khuyên bạn nên CodeIgniter. Đó là khuôn khổ nhanh nhất xung quanh, nó rất dễ dàng để tìm hiểu, và có một cộng đồng rất tích cực. Tất cả các thắc mắc của bạn sẽ được giải đáp bởi khuôn khổ:

* How your folders are designed 

CodeIgniter (hoặc bất kỳ khuôn khổ cho rằng vấn đề) tách logic của bạn vào quan điểm, mô hình, và bộ điều khiển, mỗi thư mục riêng của họ.

* Do you have a standard way of dealing with CRUD, pagination, or any other common tasks? 

CI có thư viện phân trang và thư viện thứ ba như DataMapper để gói các cuộc gọi CRUD theo cách hướng đối tượng (ORM).

* What are ways in which you can make your code more elegant? 

Việc tách riêng mô hình, chế độ xem và bộ điều khiển tạo mã rất thanh lịch.

(2 câu hỏi tôi không trả lời được khá nhiều ngụ ý khi sử dụng khuôn khổ)

Answer 6

tôi sử dụng Zend Framework, trong đó khá nhiều định nghĩa bố trí thư mục và OOP (MVC mô hình). Đối với các tác vụ thông thường, chẳng hạn như phân trang ví dụ, tôi sử dụng Zend_Paginator (các lớp mô hình của tôi thực hiện Zend_Paginator_Adapter_Interface), để xác thực tôi sử dụng các lớp Zend_Validate v.v. Nhờ đó tôi hoàn toàn có thể tập trung vào logic nghiệp vụ thay vì phát minh lại bánh xe.

Answer 7

Tôi tưởng tượng rất nhiều nhà phát triển php đã theo một lộ trình tương tự như của tôi: các script nhỏ -> procedural/inline-code -> có thể xem xét khuôn mẫu -> OOP -> sau đó là một khung công tác. Tôi nghĩ rằng nó có thể khá phổ biến đối với một nhà phát triển PHP để có "lớn lên" với PHP, học các mẫu thiết kế để phù hợp với các tính năng có sẵn với phiên bản hiện tại.

MVC là mẫu thiết kế được sử dụng thường xuyên nhất trong các khung phổ biến đang được sử dụng hiện nay. CakePHP là khung lựa chọn của tôi mặc dù Symphony và Zend cũng rất phổ biến - nó cũng đáng để thử một vài và nó sẽ sớm trở nên rõ ràng mà bạn cảm thấy thoải mái nhất.

Đối với hầu hết các dự án (nơi phát triển nhanh và mã di động là ưu tiên), tôi sử dụng Bánh, tuy nhiên đối với các ứng dụng trọng lượng nhẹ (tôi phát triển gần đây là Good Baad) mà bạn muốn chạy nhanh (trên phần cứng thấp) không cần số lượng lớn/trọng lượng được thêm vào bởi chức năng của một trong những khung công tác lớn, tôi khuyên bạn nên đọc bài viết của Rasmus Lerdorf trên No Framework PHP MVC framework của mình.

Về cơ bản nếu bạn đang theo một ngôn ngữ hướng đối tượng thực sự khuyến khích mã đẹp và các thực hành thiết kế tốt nhất, PHP luôn mất khả năng tương thích với Ruby Python và C#. Tuy nhiên, PHP có thế mạnh của nó, ví dụ: không cần cho một ngôn ngữ templating (nó là một), PHP có thể chạy rất nhanh và rẻ và không cần trọng lượng của một khuôn khổ lớn cho tất cả các ứng dụng.

Tôi muốn khuyến khích áp dụng mẫu thiết kế có khả năng quản lý của mẫu thiết kế như MVC và kết hợp nó với thế mạnh của PHP.

Answer 8

Sử dụng Zend Framework và Doctrine, cấu trúc thư mục của tôi thường trông như thế này:

root 
    app 
    config   (db config, routing config, misc config) 
    doctrine  (fixtures, migrations, generated stuff, etc) 
    lib 
    logs 
    models   (doctrine models) 
    modules  (zend mvc modules) 
    bootstrap.php 
    docs    (db diagrams, specs, coding standards, various docs) 
    pub    (web root) 
    tests 
    tools   (console tools, i.e. doctrine-cli) 
    vendor   (zend and doctrine libraries, preferably as svn-externals) 

Answer 9

Tôi đã rối tung xung quanh việc viết nội dung của riêng mình trong một thời gian và mọi lúc tôi không bao giờ có thể hoàn thành nó hoàn toàn vì tôi gặp khó khăn về điều gì đó.

Và sau đó đến phần mà tôi đến để thực hiện việc liệu tôi có làm điều gì đúng không.

Và như vậy tôi đã từ bỏ bằng văn bản của riêng tôi một đi với một đám đông yêu thích: Zend.

Tôi đã xem xét những người khác nhưng có vẻ như Zend đã tồn tại một thời gian và họ biết những điều của họ.

MVC cũng là cách tôi tiếp tục với bất kỳ điều gì tôi viết ngay bây giờ.