Kiến trúc / thiết kế ứng dụng web PHP [đã đóng]


20

Trước tiên, tôi đã bị ném vào một công việc mới phát triển các ứng dụng web trong PHP. Tôi không có nghĩa là mới đối với PHP, nhưng tôi chưa phát triển các ứng dụng quy mô lớn trước đây. Tôi đang tự hỏi làm thế nào để cấu trúc sự phát triển của mình để tránh tự đặt ra vấn đề trong tương lai. Làm cách nào để tôi thiết kế và kiến ​​trúc các ứng dụng của mình theo cách hợp lý cho phép chúng mở rộng theo thời gian về chức năng và hiệu suất. Tôi đang nghĩ về những thứ như:

  • Tách back end từ front end
  • Cấu trúc thư mục

Tôi sẽ đánh giá cao con trỏ đến các mẫu, khung và phương pháp thiết kế ứng dụng và kiến ​​trúc cho phép tôi tiếp cận phát triển ứng dụng web quy mô lớn một cách bền vững.


Chào! Kiến trúc phổ biến nhất cho các ứng dụng web là MVC , cho PHP và mọi nền tảng web phổ biến khác. Điều đó nói rằng, bạn nên đọc Câu hỏi thường gặp của chúng tôi . Mặc dù kiến ​​trúc phần mềm là về chủ đề, bạn cần xem lại câu hỏi để cụ thể hơn một chút. Một "cuộc thảo luận lành mạnh về kiến ​​trúc chung" không phù hợp với định dạng Hỏi & Đáp của trang web.
yannis

Tôi là người thường xuyên truy cập vào các trang web S / E, tôi có cảm giác sẽ không có ai trả lời cho câu hỏi này, do đó, bình luận "thảo luận". Cảm ơn con trỏ MVC mặc dù :)
Brad Morris

Câu trả lời:


29

Một sơ đồ sơ bộ về kiến ​​trúc của dự án quy mô lớn mới nhất mà tôi đã tham gia.

nhập mô tả hình ảnh ở đây

Đây chỉ là một phác thảo cơ bản, được điều chỉnh từ các tài liệu kiến ​​trúc thực tế và được trình bày theo cách giống với cách tiếp cận n tầng thông thường kết hợp với cách tiếp cận MVC điển hình . Như bạn có thể thấy logic và tầng dữ liệu được kết nối thông qua một lớp dịch vụ và cụ thể hơn là API REST , được lấy cảm hứng từ Recess , một khung công tác PHP ít được biết đến hơn.

Đừng phát minh lại bánh xe

Tôi làm việc với ba khung:

  • Khung Zend

    Các đặc điểm của các khung công tác PHP, với một cơ sở mã được viết rất ấn tượng và danh sách các tính năng mở rộng. Trên các ứng dụng quy mô lớn, bạn sẽ thấy mình điều chỉnh khung thường xuyên hơn không và tôi thấy cơ sở mã của ZF là cách dễ chịu nhất để làm việc. Nhưng hãy cẩn thận, nó không phải là một khung cấp nhập cảnh .

  • Kohana

    Kohana khởi đầu là một nhánh của CodeIgniter, và đó là lý do đủ để tôi không sử dụng nó, ban đầu. Ngày nay, nó đã phát triển thành một khung vững chắc và thanh lịch, khác biệt với nhau bằng cách làm theo cách tiếp cận MVC phân cấp . HMVC cho phép mở rộng mô đun hóa nhiều hơn so với MVC . Đối với dự án trong sơ đồ, tôi đã điều chỉnh HMVC của Kohana thành ZF, nhưng tôi đã bắt đầu sử dụng Kohana cho các dự án nhỏ hơn và xem xét nó cũng lớn hơn.

  • CodeIgniter

    Tôi chỉ sử dụng nó vì một dự án cũ mà tôi được thừa kế, tránh nếu có thể.

Như các câu trả lời khác đã chỉ ra, một ORM luôn có ích. Tôi sử dụng Doctrine một cách rộng rãi và bạn nên xem qua các trình ánh xạ hoàn toàn mới của nó cho CouchDBMongoDB . Khả năng mở rộng là bắt buộc trên các ứng dụng quy mô lớn và bạn nên đánh giá các giải pháp NoQuery .

Tất cả những gì đã nói, điều quan trọng cần nhớ là các ứng dụng lớn hơn thường có những thách thức độc đáo. Bạn nên đánh giá mọi giải pháp phổ biến của bên thứ ba, và có thể bạn sẽ thu được rất nhiều từ một vài giải pháp tối nghĩa. Khi tôi lần đầu tiên đánh giá Recess, nó đã không còn sản xuất nhưng cách tiếp cận của nó về cơ bản đã đưa nó vào dự án.

Hiệu suất

Trên các trang web điển hình, bạn có thể thoát khỏi bộ đệm ẩn đầu ra đơn giảnbộ đệm ẩn opcode nhưng trên các ứng dụng quy mô lớn, bạn thực sự nên xem xét bộ nhớ đệm, mà phổ biến nhất là xây dựng xung quanh memcached .

xdebug hầu hết được biết đến như là một trình gỡ lỗi, nhưng cũng có thể phục vụ như một trình lược tả . Gần đây tôi đã bắt đầu sử dụng Zend Server và tôi hoàn toàn yêu thích các tính năng theo dõi mã của nó . Thật không may, những thứ đó không có sẵn trong Phiên bản cộng đồng , nhưng xdebug là một lựa chọn khá tốt.

Nếu bạn đang sử dụng Apache, hãy đảm bảo tối ưu hóa địa ngục khỏi nó . nginxlighttpdsự lựa chọn rõ ràng tốt hơn , hiệu suất khôn ngoan, nhưng tôi đã không sử dụng chúng rất nhiều và tôi có thể không thực sự nói.

Đối với cơ sở dữ liệu, bộ nhớ đệm kết quả và truy vấn của Doctrine hoạt động kỳ diệu, đặc biệt là kết hợp với memcached . Và tất nhiên, chúng ta không thể quên về mặt trước. Nhóm Hiệu suất Đặc biệt của Yahoo đã tập hợp một danh sách các thực tiễn tốt nhất . Tôi không thực sự là một nhà phát triển front end, nhưng tôi đã thấy kết quả tuyệt vời trong các dự án solo.

Cuối cùng PHP có một thương hiệu mới cơ chế thu gom rác , đáng để xem xét.

Bảo vệ

Thế giới bảo mật PHP là hỗn loạn, để nói rằng ít nhất. Tôi không phải là chuyên gia, vì vậy hãy coi những điều sau đây là những lời khuyên chung chung:

  • Dự án bảo mật ứng dụng web mở

    Có rất nhiều thứ hay ho ở đó, nhưng để có cái nhìn tổng quan nhanh, bạn nên bắt đầu với danh sách mười mục hàng đầu . Và nghiên cứu các giải pháp PHP cho các lỗ hổng phổ biến.

  • Lỗ hổng ngăn xếp

    Một thói quen tốt là định kỳ theo dõi các lỗi mở của PHP . Ngay cả khi bản thân bạn không phải là chuyên gia, hầu như luôn có những lời khuyên giải quyết về các mối đe dọa bảo mật. Và tất nhiên, bạn nên mở rộng thói quen đến mọi phần khác của ngăn xếp, đặc biệt là những phần dễ bị tổn thương nhất, như máy chủ web và cơ sở dữ liệu.

Đám đông tại IT Security Stack Exchange có thể giúp bạn có câu trả lời có học thức hơn.

đọc thêm


1
Câu trả lời chính xác; trình bày tuyệt vời; bố trí tuyệt vời ... Công việc tuyệt vời!
Năng động

@Jae Cảm ơn! Bạn đã đọc tất cả? : P Nó hơi dài, tôi đã tự hỏi liệu tôi có nên cắt tỉa nó một chút không.
yannis

Ha, tôi đã thử! ;-)
Động

Thật ra là Yannis, tôi có một câu hỏi cho bạn. Gần đây tôi đã rất quan tâm đến PHP. Tôi đã cố gắng tự học, nhưng tôi gặp một chút rắc rối. Có vẻ như bạn cũng khá giỏi với PHP :-). Bạn có muốn chia sẻ một chút hướng dẫn? Nếu vậy, tôi sẽ tạo một phòng chat.
Năng động

Đó chính xác là loại câu trả lời tôi đang tìm kiếm! Đó là một địa ngục của rất nhiều thông tin để đưa vào, tôi nghĩ rằng tôi phải làm một số việc hấp thụ và mày mò trong giờ tiếp theo nhưng bạn đã cho tôi một nơi nào đó để bắt đầu. Cảm ơn :)
Brad Morris

1

Trang web developerworks của IBM có một đống bài viết PHP rất lớn , rất nhiều trong số đó khá tốt. Họ có một loạt bài viết so sánh các khung web PHP và một loạt khác về các trang web sử dụng khung CakePHP .

Trang web "Onlamp" cũ của O'Reilly có một bài viết về MVC trong PHP . Tác giả của bài báo đó đã đi đến giải thích MVC một cách chi tiết .

Các bài viết của O'Reilly hơi cũ, nhưng chúng sẽ giúp bạn tiếp tục. Các công cụ dành cho nhà phát triển của IBM thực sự tốt và bao gồm rất nhiều điều bạn đang yêu cầu.


1

Tôi đã làm việc xung quanh PHP được vài năm rồi. Tôi đồng ý với Yannis rằng câu hỏi này bằng cách nào đó mở, tôi nghĩ rằng tôi sẽ cho bạn một vài gợi ý. Đầu tiên, như Yannis đã nói, yu nên xem xét MVC, để làm như vậy, hai khung công tác tôi có thể đề xuất là CodeIgniterSymfony . Cái đầu tiên rất nhẹ và rất dễ để bắt đầu, tuy nhiên, bạn có thể chỉ cần thêm một số tùy chỉnh bổ sung để có một thiết lập đẹp hoạt động, sẽ sớm được sử dụng. Symfony là một dự án được bắt đầu bởi Fabien Potencier , sử dụng nhiều mẫu thiết kế trong công nghệ phần mềm, tuy nhiên, đường cong học tập dốc hơn nhiều so với CodeIgniter .

Bây giờ, thứ hai, bạn nên xem xét kết nối cơ sở dữ liệu, đưa tôi vào hai khung ORM nổi bật nhất cho PHP, DoctrinePropel . Cá nhân tôi yêu Propel và thậm chí đã viết về cách thiết lập một Propel sạch cài đặt trên CodeIgniter ứng dụng dựa, tuy nhiên, Symfony là hơn vào học thuyết , nhưng chúng ta hãy bạn sử dụng một trong hai. Nếu bạn muốn xem thêm một chút về Học thuyết và Tuyên truyền , hãy xem câu hỏi này tôi đã hỏi cách đây một thời gian.

Cuối cùng, bạn nên xem xét một khuôn khổ tạo khuôn mẫu, như Smarty , Dwoo hoặc Twigg . Smarty là lâu đời nhất và do đó ổn định nhất. Dwoo thừa hưởng từ Smarty và thêm một hoặc hai điều để hỗ trợ OOP tốt hơn trên PHP 5. Cuối cùng Twigg là giải pháp thay thế khuôn mẫu được cung cấp cho nhóm Symfony , tôi đã không thấy điều đó nhưng nếu nó đến từ nhóm Symfony thì thật tuyệt .

Hy vọng toàn bộ bài giảng này có ý nghĩa gì đó, David

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.