Đi từ khuôn khổ sang không có khuôn khổ [đã đóng]


89

Tôi đã phát triển PHP được khoảng 8 năm như một sở thích. Vào năm 2009, tôi chọn codeigniter và kể từ đó tôi không thể phát triển được một dự án nào.

Tôi thấy nó làm tôi chậm lại khi cố gắng tìm ra cách sửa đổi nó để hoạt động theo cách tôi muốn, nếu tôi đang làm việc bằng PHP thuần túy, tôi sẽ biết, hoặc tôi có thể nhanh chóng tìm thấy một đoạn mã.

Tôi đã thử CodeIgniter, Kohana và Symfony. Tôi thích sự dễ sử dụng (và tôi cũng đã bắt đầu sử dụng học thuyết như một ORM để tăng tốc công việc cơ sở dữ liệu của tôi một cách ồ ạt), nhưng tôi thấy rằng các dự án đang tiêu tốn của tôi gấp 3-4 lần thời gian mà nó cần trong PHP thuần túy. Tôi cảm thấy buồn chán và thất vọng khi không thể tìm ra giải pháp cho vấn đề mà tôi đã giải quyết trước đây bằng PHP thuần túy.

Có ai đã quay trở lại từ việc sử dụng các khuôn khổ sang cách tiếp cận không có khuôn khổ. Có bất kỳ điều gì giống như một khung bảo mật cơ bản (ngăn chặn XSS, lọc dữ liệu đã đăng, cung cấp chức năng dọn dẹp để sử dụng với cơ sở dữ liệu) không? Tôi nghĩ những thứ như vậy sẽ có lợi cho tôi hơn nhiều so với một khuôn khổ quy mô đầy đủ. Tôi nghĩ rằng học cách làm việc với các framework đã dạy tôi rất nhiều, nhưng tôi sẽ hạnh phúc hơn khi làm việc với mã của riêng mình.


5
Tôi rất muốn nghe thêm về lý do tại sao bạn nói về việc sử dụng framework chiếm 3-4 lần thời gian so với không có framework .. bạn có phiền giải thích thêm về điều đó không?
Lukman

7
Một trong những lợi ích của CI, hoặc bất kỳ khuôn khổ nào, là nó buộc bạn phải thiết kế theo mẫu mà các nhà phát triển không quen với phong cách phát triển cụ thể của bạn sẽ dễ dàng duy trì hơn. Ngoài ra, trong các môi trường lớn hơn, việc tách các chế độ xem khỏi logic là điều cần thiết để các chuyên gia CSS của bạn có thể thực hiện công việc của họ mà không cần dẫm chân lên các nhà phát triển.
Kyle Noland

1
Câu hỏi tuyệt vời, nếu tôi có một sự lựa chọn, tôi sử dụng PHP thuần túy. Nhưng hầu hết thời gian, những người tôi làm việc muốn tôi sử dụng một khuôn khổ, vì vậy tôi chỉ tính thêm giờ cho họ :) Tôi cảm thấy như mã của riêng tôi có thể đọc được, được tổ chức tốt và ổn định. Có lẽ họ sợ phải giữ bạn trên máy bay nếu thảm họa xảy ra và tất cả mã ở trạng thái "your-custom-framework-that-noone-else-can-read".
SSH này

Câu trả lời:


101

Các phiên bản hiện tại của PHP5 bao gồm nhiều khung bảo mật mà bạn đang tìm kiếm như một phần của thư viện chuẩn.

Nếu bạn đang chấp nhận HTML làm đầu vào, tôi khuyên bạn nên lấy HTML Purifier và gọi nó qua dòng FILTER_CALLBACK trong thiết lập filter_input_array của mình. Cách tiếp cận dựa trên danh sách trắng của nó đối với bảo mật đầu vào tạo nên một tuyến phòng thủ đầu tiên tuyệt vời (và rất mạnh mẽ) chống lại XSS.

Theo như tôi có thể nói, PHP không có cơ chế bảo vệ chống lại việc giả mạo yêu cầu trên nhiều trang web , nhưng tôi chắc rằng Google có thể giúp bạn với cơ chế đó. Bảng kiểm tra bảo mật OWASP bao gồm một phần trên đó nếu bạn muốn triển khai biện pháp bảo vệ của riêng mình.

Vì tò mò, tôi quyết định cũng bắt đầu xem xét các thành phần độc lập và đây là những gì tôi đã tìm thấy cho đến nay:

Tạo mẫu:

  • Kế thừa mẫu PHP (PHP thông thường cộng với kế thừa mẫu)
  • TWIG ( Cú pháp kiểu Django / Jinja2 / Liquid bao gồm autoescape và sandboxing. Biên dịch sang PHP được lưu trong bộ nhớ cache để tăng tốc độ.)
  • Dwoo (Một phiên bản kế thừa PHP5-ish nhanh hơn, nhiều tính năng hơn cho Smarty . Bao gồm hệ thống tương thích cho các mẫu Smarty hiện có.)

Nội dung tôi vẫn chưa xem xét chính xác:

  • Điều phối tuyến đường (Chỉ tìm thấy RouteMapNet_URL_Mapper cho đến nay. Cảm ơn, cweiske.)
  • ORM (Đề phòng PDO trần không phải là thứ của bạn)

Cảm ơn, tất cả những lời khuyên rất tốt và tôi sẽ bắt đầu xem xét chúng ngay bây giờ!
Alex C

4
Đổi Smarty cho Dwoo nếu bạn cần một công cụ tạo khuôn mẫu. Về mặt đặc điểm, nó gần giống với Smarty nhưng không làm tan chảy CPU.
Phil Sturgeon

Pear.php.net/package/Net_URL_Mapper là một trình điều phối tuyến đường.
cweiske

4
Nếu các khuôn khổ làm chậm bạn thì hãy tránh các công cụ tạo khuôn mẫu, đặc biệt là Smarty, giống như bệnh dịch. Chúng có ý nghĩa tốt nhưng chúng chỉ tạo ra một cách mới và không trực quan để làm điều gì đó mà PHP đã làm.
Cú đêm

Phụ thuộc vào những gì bạn đang cố gắng hoàn thành và lý do tại sao khuôn khổ chỉ làm bạn chậm lại.
ssokolow

10

Tôi không tin vào các khuôn khổ ... Tôi đã làm việc trong rất nhiều khuôn khổ.

Lý do ghét khuôn khổ MVC:

1) Code bloat, tôi mua các lớp cao cấp hỗ trợ tôi phát triển. Chẳng hạn như lớp biểu mẫu hoặc lớp SQL.

2) Tôi tin rằng các khuôn khổ MVC không dễ dàng di chuyển đặc biệt là khi sử dụng trình quản lý phụ thuộc.

3) Tôi tin rằng bạn thực sự viết nhiều mã hơn với khuôn khổ MVC sau đó nếu bạn phải sử dụng một bảng soạn sẵn với rất nhiều lớp hữu ích xử lý xác thực, v.v.

4) Hầu hết các khuôn khổ cũng chỉ phục vụ cho một hoặc hai cơ sở dữ liệu nguyên bản.

Tôi khuyên bạn nên tìm một khung biểu mẫu có xác thực và trình soạn thảo văn bản & một khung sql như madoo + một lớp email ...

90% đơn đăng ký của bạn luôn là biểu mẫu, LỚP sql & ajax - phần còn lại chỉ có thể nhận được khi cần

Tôi là một người theo chủ nghĩa tối giản và tôi đấu tranh với ý tưởng có mã trong ứng dụng của tôi mà không làm được gì cả ... đề phòng trường hợp tôi cần, nó không hoạt động với tôi.


Về tuyên bố "Tôi mua các lớp cao cấp": bạn mua các lớp đó từ đâu, và cho mục đích gì? Cảm ơn.
dotancohen

Tôi đồng ý. Ngoài ra, có một hiệu suất khá lớn đạt được với rất nhiều khuôn khổ.
developerbmw

8

Với nhiều kinh nghiệm đằng sau bạn, bạn phải có bộ thư viện yêu thích của riêng mình, tự tay chọn chúng và đưa ra khuôn khổ đơn giản của riêng bạn. Khung hoặc không có khung (và cái nào ở cái đó) phụ thuộc vào loại dự án hiện tại, không có găng tay nào phù hợp với tất cả. Vì vậy, tôi thực sự khuyên bạn rằng nếu bạn cảm thấy rằng các khuôn khổ hiện có đang làm bạn chậm lại, hãy dành thời gian và tìm ra một khuôn khổ hoạt động theo nhu cầu của bạn.


8

Dựa trên tuyên bố của bạn rằng bạn đã sử dụng PHP như một sở thích, cũng như tuyên bố hồ sơ của bạn "Từ từ sẽ đến đó", đây có vẻ như là một vấn đề về đường cong học tập. Bạn dường như không có bề dày và kinh nghiệm để a) hiểu cách làm việc trong cấu trúc mà khuôn khổ áp đặt và b) do đó bạn không thể hưởng lợi từ những hiệu quả mà khuôn khổ cho phép.

Tôi mong bạn gắn bó với nó. Quay lại đầu với các video hướng dẫn. Tìm và đọc mã của những người khác cho đến khi bạn hiểu nó. Xây dựng các dự án của bạn từ dưới lên - bắt đầu đơn giản và thêm chức năng. Theo dõi các diễn đàn, cố gắng tự trả lời các câu hỏi trước khi đọc các câu trả lời.

Tôi đã lập trình chuyên nghiệp được gần 20 năm, trên nhiều nền tảng khác nhau và tôi vẫn mất một thời gian để trở nên thoải mái với CI. Nhưng bây giờ, tôi sẽ không quay lại với PHP thuần túy (cho các dự án của riêng tôi) trừ khi tôi có một trang web đủ quy mô để nó bộc lộ các vấn đề về hiệu suất có thể định lượng được (nghĩ rằng Twitter).


Tôi vẫn đang ở trong ranh giới cho dù tôi có thích các khuôn khổ hay không. Tôi chắc chắn thấy quan điểm của OP, nhưng tôi cũng thấy của bạn ... học một framework giống như học một ngôn ngữ hoàn toàn mới. Bạn phải đi vào cách làm việc của khuôn khổ. Tuy nhiên, một điều khác mà tôi đấu tranh là liệu triết lý của tôi về cách mọi thứ nên được thực hiện có khác với triết lý của khuôn khổ hay không. Tôi vẫn đang cố gắng tìm một cái phù hợp với mình. (Không thể đợi .NET MVC3)
mpen 12/09/10

Vì tôi không biết bất kỳ khuôn khổ nào khác, vì vậy tôi không thể nói một cách tổng quát. Nhưng sử dụng một khuôn khổ không phải là một đề xuất tất cả hoặc không có gì. Ví dụ: tôi thấy các thư viện bộ nhớ đệm của CI (trang, cơ sở dữ liệu) không đủ và không dễ mở rộng. Vì vậy, tôi sử dụng thư viện bộ nhớ cache của bên thứ ba (của Phil Sturgeon) và tôi khá hài lòng với nó.
coolgeek 13/09/10

Một lợi thế đáng kể khác để gắn bó với nó là nó giúp cho việc học các framework khác sau đó trở nên tương đối dễ dàng. Đây là lý do tại sao bạn thường xuyên thấy danh sách việc làm chỉ định một khuôn khổ cụ thể (giả sử, CI), nhưng việc nêu rõ kinh nghiệm với các khuôn khổ tương tự (ví dụ như Zend hoặc Symfony) sẽ được xem xét.
coolgeek 13/09/10

2

Zend Framework thực sự tuyệt vời cho điều đó. Bạn có thể sử dụng nhiều hoặc ít tùy ý. Tất cả đều được mã hóa bằng php và có nguồn mở nên bạn có thể hack và biến nó thành của riêng mình. Các thành phần khác nhau không phụ thuộc vào eachothers nhiều như trong các khuôn khổ khác.

Bạn có thể xây dựng cho mình một khuôn khổ đơn giản bằng cách sử dụng một số thành phần từ Zend mà không gặp bất kỳ vấn đề gì.

Kiểm tra nó ra!


3
Anh ấy đang cố gắng thoát ra khỏi khuôn khổ.
WarmWaffles

1
@WarmWaffles. Đó là lý do tại sao tôi nói về việc sử dụng các phần của ZF. Chắc chắn bạn không mong đợi anh chàng sẽ phát minh lại bánh xe cho mọi thứ.
Iznogood

2
Iznogood có một điểm rất hay. ZF không chỉ là một khuôn khổ. Tôi thấy các gói này cực kỳ hữu ích để thực hiện nhiều tác vụ thông thường và không có gì về nó buộc bạn phải sử dụng các mẫu MVC hoặc các phương thức truy cập DB của chúng hoặc thực sự là bất cứ điều gì. Tất nhiên, bạn cũng có thể sử dụng mô-đun Pear.
Bob Baddeley

2
Đó là một thư viện vâng cũng thể thao một khuôn khổ. Tuy nhiên, anh ấy đang tìm kiếm thứ gì đó dễ sử dụng, và lần trước tôi đã kiểm tra không gian tên của Zend bị lộn xộn và rất khó gõ. @Bob_Baddeley PEAR là một gợi ý hay
WarmWaffles

@WarmWaffles Tôi đoán là mỗi người của riêng mình. Có lẽ bạn có thể kiểm tra lại Zend của nó ở 1.10.x bây giờ và khá khác rồi nói 1.8.
Iznogood

2

Tôi biết chính xác cảm giác của bạn. Tôi đã bắt đầu từ 4 ~ 5 năm trước với PHP (tôi đến từ Delphi, lol), và bắt đầu bằng php thuần túy. Những gì tôi có lại cho họ là một "CMS Panel như" chỉ cần đọc tất cả các trường bảng và tạo biểu mẫu. Sau một thời gian tôi đã đạt được kiến ​​thức về PHP Framework, tôi đã thử CakePHP lần đầu tiên và không thích, sau đó, tôi đã sử dụng Yii vì theo ý kiến ​​của tôi là nó khá trực quan và dễ sử dụng (Với trình tạo Gii, nó khá tuyệt). Tôi đã thử Symfony, ZF2, Laravel, Yii2-Beta và một số khung công tác cho RAD, nhưng tôi vẫn cảm thấy không đủ nhanh như trước đây.

Đã xảy ra việc tôi phát triển khung công tác của riêng mình (Đó là một cách tự nhiên, không hẳn là một ngày nào đó tôi thức dậy và nói rằng "Tôi sẽ tạo một khuôn khổ mới", đã xảy ra cùng thời điểm). Tôi biết đó là một hành động tồi tệ tồi tệ và động thái "tái tạo lại bánh xe", NHƯNG, bây giờ tôi phát triển các dự án của mình nhanh hơn nhiều (chỉ hơn PHP).

Vì mã của nó là một MESS hoàn toàn, tôi đã bắt đầu cách đây khoảng một tháng để định dạng lại khuôn khổ của mình, bây giờ nó sử dụng trình soạn nhạc, tuân theo các quy tắc chung tồn tại giữa các khuôn khổ php, là MVC.

Tại sao tôi đang định dạng lại? Bởi vì nếu ai đó cần sửa chữa một dự án của tôi, đó sẽ không phải là một điều của thế giới khác.

Vì vậy, tôi hiểu bạn.

Lời khuyên của tôi là, hãy chuẩn bị các công cụ của bạn (gọi nó là một khuôn khổ, một ứng dụng cài sẵn hoặc bất cứ thứ gì mọi người đặt tên cho nó) và sử dụng nó theo cách bạn cảm thấy tốt hơn, nhưng vẫn tuân theo một số quy tắc chung (Giống như MVC, những thứ "dễ mô-đun" sẽ bạn có thể thay thế trong trường hợp bị hỏng.


1

Để bảo mật cơ bản, tôi sử dụng phương pháp lọc tùy chỉnh để bao bọc các siêu cầu thủ của tôi . Cú pháp của nó cần một số người làm quen, nhưng đơn giản hơn API filter_var () của PHP và không cho phép bạn làm sạch:

 $_GET->text("inputvar") or $_POST->name["field"]

Nó cũng cho phép thoát nội tuyến $ _REQUEST-> sql (). Nhưng đối với công việc cơ sở dữ liệu, hãy tiếp tục sử dụng SQL được tham số hóa hoặc DAL / ORM của bạn.


Đó chắc chắn là một giải pháp thông minh, nhưng tôi không chắc tại sao bạn cho rằng API bộ lọc là cồng kềnh. Nếu có gì, tôi nghĩ filter_input_array () là tuyệt vời. (Chủ yếu bởi vì nó làm cho nó đơn giản để xác định tất cả các yếu tố đầu cho một loại yêu cầu nhất định ở một nơi trong một thời trang một cách hợp lý declarative Không bao giờ đánh giá thấp lợi ích của kiểu công việc đó..)
ssokolow

@ssokolow: Thật vậy, filter_input_array () rất tiện lợi khi thực hiện nó chỉ trong một lần. Tuy nhiên, đã có quá nhiều tính linh hoạt trong các hàm filter_ * và quá nhiều tham số không phù hợp với nó. Đó là lý do tại sao tôi nghĩ mọi người đang tránh nó (mặc dù về mặt kỹ thuật thì đó là một giải pháp tốt).
mario

Có lẽ. Tôi nghĩ một phần của vấn đề là, ngoài việc gần đây đã đến một thế giới mà nhiều người vẫn có sách PHP4 trên kệ của họ, nó được quảng cáo quá ít, tài liệu chính thức không đủ rõ ràng và tài liệu của W3Schools xu hướng chia sẻ kết quả hàng đầu của Google không đủ toàn diện.
ssokolow

1

Tôi đã thực hiện một nghiên cứu một ngày về ToroPHP và thấy nó khá hay. Nó là một khung công tác tối giản nhắm đến các ứng dụng RESTful. Điều này làm cho nó có thể giữ cho mã phía máy chủ theo mô-đun, mà không phải đối phó với sự cồng kềnh của bất kỳ khuôn khổ nào.


1

Tôi không biết điều gì đang làm phiền bạn nhưng codeigniter là một framework tuyệt vời, nó có tài liệu hay và vì rất nhiều người sử dụng codeigniter nên bạn sẽ tìm thấy tất cả sự trợ giúp trong tài liệu của nó, diễn đàn hoặc trên stackoverflow. Tôi đã làm việc trên nhiều framework ( Codeigniter, CakePHP, Zend, Spring 3.0, Ruby on Rails), nhưng tôi phải nói rằng codeigniter có tài liệu tốt nhất.Có rất nhiều thứ trong codeigiter được xử lý tự động và bạn không phải lo lắng về bảo mật. Làm việc trên lõi PHP giống như phát minh lại bánh xe. Chà, điều quan trọng nhất là việc chuyển từ một cốt lõi sang một khung công tác sẽ cần rất nhiều nỗ lực của bạn khi bạn đã quen với nó, bạn sẽ bắt đầu yêu thích nó. Ngoài ra Ruby on rails cũng là một khung công tác tuyệt vời một khi bạn biết rõ các đặc điểm của nó thì bạn có thể có tốc độ gấp đôi.


2
Chỉ hơn hai năm kể từ khi tôi đăng bài này và tôi thực sự đã làm việc với PHP thuần túy trong một thời gian, nhưng kể từ khi chuyển đổi trở lại PHP - bạn nói chính xác, nó cực kỳ dễ sử dụng. Thiết lập ưa thích hiện tại của tôi là CI, phpActiveRecord cho cơ sở dữ liệu và Twig để tạo khuôn mẫu.
Alex C

Vâng, phpActiveRecord có vẻ đẹp. Bạn đã bao giờ thử Laravel chưa? ( laravel.com ) Tôi nghĩ bạn sẽ thấy nó có các tính năng tốt nhất của CI, phpActiveRecord và Twig, tất cả đều được tích hợp sẵn theo mặc định. Bản thân tôi cũng là một nhà phát triển CakePHP, nhưng gần đây rất quan tâm đến Laravel.
Simon East
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.