地球上的大熊, 巧遇上火星的你

[思考]使用/不使用framework?

@ 2011-5-7 10:28 AM

熊小這幾天在研究使用php framework(比較了CakePHP, Zend, symfony,Yii, CodeIgniter)…最後決定使用其中號稱最快的CodeIgniter...它不難…基本使用花一點點時間也可以學會。

有mvc…有helper class…好像蠻好的。就決定用下來…

剛才正式coding時…發現一些很簡單的東西也要call extra function或去了解framework的構架

例如在header...加入css檔

不用framework…自己寫就直接
<link rel="stylesheet" type="text/css" media="all" href="css/xxx.css" />

但在使用codeigniter的情況下

如果沒有使用mod_rewrite
1. css放到web_root, 那不是跟views分開了?

如果有使用mod_rewrite來hide inde.php(front controller)
1. 修改.htaccess容許css folder
2. 於你的controller使用helper,$this->load->helper('url');
3. 於header page的css加到helper的base_url()
<link rel="stylesheet" type="text/css" media="all" href="<?=base_url()?>css/xxx.css" />

嘩…我其實只想加css到header就要弄懂這樣多background logic…

另一個問題是這些framework大部份都使用front controller...每個request都必須經過這controller再分配到真正的response....但網絡要求很多都是分散的…如大家看到這篇是以viewthread.php來處理…搜索是以search.php來處理…全部都丟給單一的controller效率應該比較差吧?

也許大家說用framework來支援mvc…但如果只是mvc…其實自己將php code(再分開model與control也可以)與html分開…於每個php最後include負責view的html就可以。不必因為要用mvc而使用整個framework…

除非我們去了解整個framework的運作與建造(但這不正正跟「用framework來省時間」的理論相反了嗎?)…否則有些問題…甚至很基本的…如之前提到的include css…都可能要花一些時間才能解決。

自己建一個基本的mvc很簡單…更不需要單一的front controller...將request直接交給負責的page…如果要code reuse...OO來寫…也可以套用別人的OO…再extends…

想想…那到底使用php framework還有什麼好處?

6 評論

想想不如弄個既簡單也適合自己的framework比較利於將來發展…

有什麼欠缺的…就去(抄)考其他framework

發佈者 : Vic 等級: 32等級: 32等級: 32等級: 32等級: 32等級: 32等級: 32等級: 32  @ 2011-5-7 12:57 PM

誰有使用php framework的經驗可以分享一下?

發佈者 : Vic 等級: 32等級: 32等級: 32等級: 32等級: 32等級: 32等級: 32等級: 32  @ 2011-5-8 12:01 AM

我上班是用cakephp
css也是在controller的地方設定
但是只要pass一個css的路徑array到view file即可

單一controller的確會讓速度變慢
像是cakephp
你必須在一開始宣告你需要用的model (table)
然後無論那個page在哪個controller被call
都會把那些model建成object
無論這個page有沒有用到(雖然也有方法避免這樣)

但是好處是 好整理
我們公司那個 目前controller就有十幾個
80%都是ajax call (沒有view)
一個file一個寫的話 會蠻累的

發佈者 : ash11tw 等級: 4  @ 2011-5-8 11:05 PM

謝謝ash11tw兄的經驗分享…cakephp好像是號稱最慢的framework (可能是內建功能太多)

題外話,這幾天熊小也在看有關design pattern的東西~ 因為考慮會不會有適合自己的pattern

其實他們的概念並不簡單…就算是理論面不難了解的…轉換成真正coding時也不直觀…

很多所謂的re-usability...都建基些複雜的layer…

我覺得除非是很有經驗的pattern coder…否則要在一大堆的objects與它們的relationship了解現有的系統…一點都不容易。

也許就是因為這樣…可需要推廣design pattern…大家都知道什麼是observer,什麼是singleton後…那些以此建立的系統才可以讓人看明白。

發佈者 : Vic 等級: 32等級: 32等級: 32等級: 32等級: 32等級: 32等級: 32等級: 32  @ 2011-5-9 11:36 PM

剛看到一些不錯的文章...跟大家分享一下

Why Write A New Framework?

Summary
A framework is essentially a way to put all of your best practises into a single place so that you can reuse them over and over again. This should make you more efficient and make your time more financially viable to clients. If the framework you use slows you down or does not cater for the way you like to develop then sack it off and do your own thing. A vast majority of the framework community seems to have a massive fanboy attitude which is totally unneccessary. You can use a framework for a few years then change your mind and write a few apps in a different one. It doesn't make you a traitor, it just makes you a free thinking logical developer who uses the best tools for the job at the right time.

Use whatever you like and don't be negative to anyone who wants to work in a different way. There is no one framework that does everything right for everyone and there never will be. I have my three favourites and I'll be using those until I change my mind. I prefer to have my options and you're welcome to yours, just don't tell me I'm wrong for wanting to work in the best way I can or I won't have anything polite to say.


.....................

在他回應的文中有一段

There is so much great stuff in Rails, such as the irb, Migrations, Scaffolding, etc but at the same time there is stuff that drives me mad. I can't manually assign an ID to anything in ActiveRecord for example. But beyond that is a knowledge gap. I can spend 20 minutes and build something absolutely amazing with Rails, but then I can spend a day wrestling with inconsistent date formatting in my queries across environments or some other trivial task and all the productivity that Rails and it's auto-magic provides is shot out the window and things are made uncontrollably late.

http://philsturgeon.co.uk/blog/2011/04/why-write-a-new-framework



The Framework Myth

One of the key points here is that the framework is dictating the application flow, rather than the developer who is using it. This is what the Martin Fowler (who literally wrote the book on refactoring) would describe as a Foundation Framework:

A Foundation Framework is … built prior to any application that are built on top of it. The idea is that you analyze the needs of the various applications that need the framework, then you build the framework. Once the framework is complete you then build applications on top of it. The point is that the framework really needs to have a stable API before you start work on the applications, otherwise changes to the framework will be hard to manage due to their knock-on effects with the applications.

While this sounds reasonable in theory, I’ve always seen this work badly in practice. The problem is that it’s very hard to understand the real needs of the framework. As a result the framework ends up with far more capabilities that are really needed. Often its capabilities don’t really match what that the applications really need.


He recommends instead a Harvested Framework:

To build a framework by harvesting, you start by not trying to build a framework, but by building an application. While you build the application you don’t try to develop generic code, but you do work hard to build a well-factored and well designed application.

With one application built you then build another application which has at least some similar needs to the first one. While you do this you pay attention to any duplication between the second and first application. As you find duplication you factor out into a common area, this common area is the proto-framework.

As you develop further applications each one further refines the framework area of the code. During the first couple of applications you’d keep everything in a single code base. After a few rounds of this the framework should begin to stabilize and you can separate out the code bases.

While this sounds harder and less efficient than FoundationFramework it seems to work better in practice.


http://www.simple-talk.com/opini ... the-framework-myth/


發佈者 : Vic 等級: 32等級: 32等級: 32等級: 32等級: 32等級: 32等級: 32等級: 32  @ 2011-5-14 12:08 AM

每個人寫程式的風格不一, 一個 framework 也不是每個人都能適用
以自己的經驗, 以 php 來說, 類似的爭議從以前到現在就常常出現
像是 template, 有人認為 smarty 好用, 但也有人認為 php 本身就是 template 的架構
還有 php 和 jsp , asp.net 的比較

個人認為, 要不要用, 好不好用, 是根據自己的觀念與技巧來決定
之前也大約看了一下 framework 的東西, 但是發現光研究使用
與把code 轉化成該 framework 的時間, 就足夠我開發完整個
程式, 後來乾脆不用了

以現在自己有時候會寫的一些東西,  是完全不用 framework 的
只單純的以 json , javascript 來負責前端輸出頁面,  php 處理
資料, 等到開發到一個階段, 如果可以就把 php 程式包起來變成
object

所謂 model -view -control , 這也是人為去區分的, 當然有好處,就一定有壞處
好壞之間就看個人取捨, 只有適合不適合

簡單的說, 個人認為,  自己是要寫自己可以用的東西, 不是去寫要給別人用的東西
多人開發, 早有許多準則可以遵守, 命名規則,  程式文件, 撰寫規範 這些東西如果完整
開發與維護的時間並不會輸給任何一個 framework

問題就在於, 很多時候這些文件並不完整, 所以 .....

看看 phpbb , 人家也沒有用 framework , 架構還是可以很開放,
程式還是可以很好維護, 速度還是可以很快

發佈者 : beanpp 等級: 7等級: 7等級: 7  @ 2011-5-21 08:38 AM

   


  可打印版本 | 推薦給朋友 | 評分