Kiến trúc (cấu trúc) một số web framework trong thế giới PHP

[pcdinh]

PHP framework architecture

CakePHP (MVC-push):

http://pieceofcakephp.files.wordpress.com/2006/11/pieceofcakephp.png

http://pieceofcakephp.files.wordpress.com/2006/11/routing_logical_view.png

Zend (MVC-push, component framework)

http://www.codediesel.com/data/images/zend_map_large.gif

Symfony (MVC-push, Hybrid MVC-pull)

http://www.symfony-project.org/blog/2008/06/23/the-symfony-1-1-architecture


And my own framework, Pone (MVCP, MVC-pull)

http://farm4.static.flickr.com/3248/2604858688_5ab96d19cf_o.png

[Son Dat Giang]

theo kinh nghiệm của anh thì cái nào dễ phát triển hơn, kiến trúc nào
hay hơn

[Nguyễn Quốc Vinh]

Tối đó nói chuyện với anh pcdinh là e đề cập đến PONE của anh là pop(lẽ ra phải là pull)

2008/6/24 Son Dat Giang <giang...@gmail.com>:

theo kinh nghiệm của anh thì cái nào dễ phát triển hơn, kiến trúc nào
hay hơn

pull

--
/********************************************
* Người ta thưởng chỉ chú ý đến những kẻ lên như diều gặp gió! Nhưng hỡi ôi, chỉ có cát, bụi và lông hồng mới là những thứ lên nhanh nhất
*/

[BinhPham]

Pull, Push, Pop? nó có ý nghĩa gì trong kiến trúc phát triển vậy các
bác? Em chưa hiểu mong các bác chỉ giáo

On Jun 24, 9:05 am, "Nguyễn Quốc Vinh" <kureik...@gmail.com> wrote:
> Tối đó nói chuyện với anh pcdinh là e đề cập đến PONE của anh là pop(lẽ ra
> phải là pull)
>

> 2008/6/24 Son Dat Giang <giangson...@gmail.com>:

[poke]

@binhpham

Chỉ có Pull hay Push hoặc là PD không có Pop (Trong mô hình MVC).

Pull hay Push là chỉ cái quan hệ giữa Controller và View . Việc này
gây ảnh hưởng tới developer sử dụng framework đó .
Nói đơn giản thế này :

Đây là cái URL của group (nếu dùng qua web)
http://groups.google.com/group/phpvietnam/browse_thread/thread/f1103538c108db94

Thì front controller sẽ nhận action là browse_thread với tham số là
thread=f1103538c108db94 và group=phpvietnam
tạm hiểu là yêu cầu browse một thread controller sẽ dựa trên ngữ cảnh
của action để lấy dữ liệu đầy đủ cho việc hiển thị trong view
sau đó nó lưu dữ liệu vào đâu đó rồi ném cho view . View sẽ trình bày
dữ liệu nhận được hoặc lại ném cho Presentation . Cách làm này gọi là
Push .
Đa phần các web framework hiện nay là Push eg: Strut của Apache hay
CakePHP...

Còn Pull thì ngược lại . View cần gì lên controller mà lấy :D .
Cái này hay dùng trong các framework UI controll base .

Còn Pop thì tôi không biết :D .

Các framework thường đi theo 1 hướng hoặc không rõ ràng . Pull thì
phù hợp với UI framework hơn là web framework .

[pcdinh]

Không có cái hay tuyệt đối. Tương tự về sự dễ cũng vậy.

Trong MVP, điểm tiếp nhận request/event là View. View delegate cho
Presenter (hay code behind). Vậy nên đây là kiến trúc hướng giao diện,
hướng trang.

Với M$, họ mạnh về tooling cho nên họ có xu hướng đi theo MVP để giúp
developer tận dụng công cụ của bộ Visual Studio sinh ra giao diện.

Để tận dụng được điểm mạnh của MVP, M$ định nghĩa hàng tá các tag soup
mà VS.NET hiểu được nhằm giúp developer kéo thả giao diện, thay đổi
properties. Bằng cách đó, họ cho là tốc độ làm việc của developer được
cải thiện. Tuy vậy, nhìn ở góc độ chất lượng sinh trang thì VS.NET
giúp sinh ra các trang có chất lượng rất thấp và cực kì kém hiệu quả
nếu như không có sự can thiệp bằng tay từ các lập trình viên có kinh
nghiệm. Đây là một tradeoff.

Việc xây dựng giao diện phụ thuộc vào công cụ và hướng vào việc nhanh
chóng có được các thành phần của trang rời rạc sẽ làm tăng tính phức
tạp khi số lượng trang bắt đầu lớn. Số code bị duplicate ở mức độ lớn
tăng lên là không thể tránh khỏi. Chưa kể là tầng CSS là không thể bảo
trì

Điểm yếu tiếp của MVP là rất khó test web form do web form là một phần
của trang và chỉ có thể xuất hiện khi có sự kiện trên trang đó. Tiếp
đến là sự dính liền giữa logic xử lý sự kiện về logic giao diện của
từng trang. Do vậy nó khuyến khích một thứ tư duy thiếu tính modular
việc định hình kiến trúc ứng dụng. Đây là điểm yếu của ASP.NET truyền
thống (ASP.NET cũng đã có bản MVC hỗ trợ trong namespace
System.Web.Mvc --> cái tên ugly kinh dị - đúng kiểu của bác Johnson
nhà Spring).

Điểm mạnh của MVP là giúp giúp vendor hóa các UI control. Các lập
trình viên có thể đóng gói phần tag soup và code behind của nó và phân
phối lại. Trên thực tế, các UI như vậy chỉ cần thiết khi mà UI đó dùng
thật nhiều Javascript. Nhưng điều đó cũng có nghĩa là khi ứng dụng
được xây dựng bằng cách lắp ghép thì không ai đảm bảo được chất lượng,
độ nhất quán và tính tối ưu. Sẽ có rất nhiều cách code, cách sinh
trang và sự lặp lại là không thể tránh khỏi.

Đây là một ví dụ: http://travel.channelvn.net/home.chn --> hết sức
thận trọng khi dùng ASP.NET cho các site có tiềm năng trở thành cỡ
lớn.

MVP và ASP.NET sẽ có lợi thế trong các team nhỏ, hỗ trợ tool tốt và đa
kĩ năng.

Martin đã kill khái niệm MVP từ năm 2006. Vậy nên có thể gọi mô hình
của ASP.NET truyền thống và JSF là MVSC (supervising controller). Cả
hai thằng này tớ đều ghét: một thằng thì postback-oriented thằng kia
thì POST-oriented.

Với MVC thì request gửi đến controller, controller này sẽ quyết định
trang nào hiện ra. Sự tách biệt giữa Model, View và Controller là đậm
nét giúp việc phân công công việc tốt hơn (thích hợp với các team lớn,
đa dạng hóa về kĩ năng), dễ test độc lập các thành phần. Việc
controller xử lý View cũng sẽ giúp lập trình quản lý được ứng dụng tốt
hơn về workflow, hay tất cả các khía cạnh khác của aplication trước
khi sinh trang. MVC cũng hỗ trợ TDD (hoặc ít nhất là unit testing) tốt
hơn.

Tuy nhiên có rất nhiều các biến thể của MVP và MVC bên ngoài kia. Đánh
giá điểm yếu mạnh của chúng thì mất khá nhiều thời gian :D

On Jun 24, 8:51 am, Son Dat Giang <giangson...@gmail.com> wrote:
> theo kinh nghiệm của anh thì cái nào dễ phát triển hơn, kiến trúc nào
> hay hơn
>
> pcdinh wrote:
> > PHP framework architecture
>
> > CakePHP (MVC-push):
>
> >http://pieceofcakephp.files.wordpress.com/2006/11/pieceofcakephp.png
>

> >http://pieceofcakephp.files.wordpress.com/2006/11/routing_logical_vie...

>
> > Zend (MVC-push, component framework)
>
> >http://www.codediesel.com/data/images/zend_map_large.gif
>
> > Symfony (MVC-push, Hybrid MVC-pull)
>

> >http://www.symfony-project.org/blog/2008/06/23/the-symfony-1-1-archit...

[pcdinh]

Poke hiểu sai về Pull và Push một chút

Trong Java có một framework tên là Turbine. Tôi gọi nó là Bố của Phức
Tạp. Nó implements một kiến trúc là Pull MVC. Đó là khả năng pull data
từ View mà không qua Controller. Nó lấy thẳng từ Model. Turbine
designer thì cho rằng có thể định nghĩa API cho phép page designer
pull dữ liệu trực tiếp từ Model. Một số khác thì cho rằng việc kéo DTO
như vậy là ẩu nên cần có một service layer nằm giữa Model và View.
Kiểu gì thì kiểu thì Pull là quan hệ về dữ liệu giữa View và Model.

Trong MVC push, View muốn có dữ liệu thì đành nhờ Controller. Mọi
người thường thấy code mẫu sau:

Trên controller

$model = $this->getModel();
$data = $model->findUserInfoById($id);

$this->view->bindData('data', $data);

Trên CakePHP mọi người lại thấy thế này

Trên View template

$this->requestAction(....)

đó là vì CakePHP là Push MVC nên nó gọi ngược lại Controller nhờ trợ
giúp lấy data.

Trên các sơ đồ mô hình về MVC, mọi người thấy có mũi tên chỉ quan hệ
giữa View và Controller. Quan hệ này về thực chất là notification. Với
quan hệ kiểu thông báo này, View được đăng kí vào Controller để nhận
dữ liệu về từ Model. Còn trong mô hình Pull, View khỏi đăng kí với ai,
nó tự chịu trách nhiệm gọi Model mà nó muốn.

Phần này đã được Sun viết doc như sau: View -The view renders the
contents of a model. It accesses enterprise data through the model and
specifies how that data should be presented. It is the view's
responsibility to maintain consistency in its presentation when the
model changes. This can be achieved by using a push model, where the
view registers itself with the model for change notifications, or a
pull model, where the view is responsible for calling the model when
it needs to retrieve the most current data.

Mời bà con http://java.sun.com/blueprints/patterns/MVC-detailed.html

On Jun 26, 11:43 am, poke <buidinhngoc.a...@gmail.com> wrote:
> @binhpham
>
> Chỉ có Pull hay Push hoặc là PD không có Pop (Trong mô hình MVC).
>
> Pull hay Push là chỉ cái quan hệ giữa Controller và View . Việc này
> gây ảnh hưởng tới developer sử dụng framework đó .
> Nói đơn giản thế này :
>

> Đây là cái URL của group (nếu dùng qua web)http://groups.google.com/group/phpvietnam/browse_thread/thread/f11035...

[zmt]

Google: Pull vs Push

http://www.guyrutenberg.com/2008/04/26/pull-vs-push-mvc-architecture/

> Mời bà conhttp://java.sun.com/blueprints/patterns/MVC-detailed.html

[poke]

@pcdinh Thanks for advanced :D

[toiyeuphp]

Vậy lợi ích là gì?

[web20vn.com]

Lần đầu tiên nghe đến kiểu MVC pull, quả là được mở rộng thêm kiến
thức. Hồi giờ em thường làm theo kiểu, tạm gọi là Library
Controller :D nó được dùng ở cả Controller lẫn View nhằm giảm thiểu
viết lại code, chắc là kết hợp của Push và Pull :D

Trong kiến trúc Pone của anh pcdinh sao Pone_Form_* lại nằm trong phần
Model mà không phải là View? Pone_TimeUtil em nghĩ là làm Pone_Util
trong đó có Time, Log, String có vẻ ổn hơn. Chắc framework này là
"Java Framework clone" chứ không phải phong cách "RoR clone".

[LNS]

Mình cũng mới nghe đến MVC-Pull. Nhưng ko hiểu có chuyển dữ liệu trực
tiếp từ Model đến View thì có lợi ích gì nhỉ? Tốc độ xử lý chăng?!
Nhưng như thế thì nó làm cho programmer mơ hồ hơn chăng? VD:
programmer cần xác định trước những dữ liệu nào có thể lấy trực tiếp
từ View hoặc dữ liệu nào cần xử lý phía Controller trước. Nhưng nếu
project vừa áp dụng MVC-Push và MVC-Pull thì làm cho dự án rắc rối,
khó bảo trì hơn chăng?

@web20vn.com: Mìh nghĩ trong Model có các Pone_Form_* là điểm khác
biệt giữa MVC-Pull và MVC-Push, có lẽ mấy lớp này lấy dữ liệu từ CSDL
và điền vào Form Element.

@pcdinh: Qua kiến trúc của Pone, em nghĩ anh pcdinh là dân Java nhiều
hơn PHP. Vì em thấy các Java Framework thường có các đối tượng
Dispatcher, Request, Response. Đúng ko anh?

Thân,

[Fadine]

Hix, pull với push
Em đang hoàn thiện một framework nhỏ bằng PHP, cũng tuân thủ theo kiến
trúc MVC, nhưng ngoài Controller thực hiện trên PHP, còn Model thì đơn
giản là file XML, View đặt hoàn toàn trên Javascript, việc truyền tải
dữ liệu thông qua ajax. Nói như các bác thì mô hình của em là mô hình
Pull vì khi có yêu cầu, trình duyệt dựa theo khai báo ban đầu (các
biến javascript toàn cục) để luận ra là cần Model nào để load về, sau
đó Javascript View sẽ xử lý giao diện, tiếp theo gửi yêu cầu tải dữ
liệu về Controller để tải về và điền đầy giao diện. Thậm chí là đối
với form nhập liệu thì trình duyệt chỉ gọi đến Controller khi đã có
đầy đủ dữ liệu và yêu cầu ghi lại.

Em nghĩ mô hình này hay vì tận dụng được client agent, giảm tải tối đa
cho server. Thậm chí các Model có thể đặt ở máy chủ khác. Nói cách
khác là tận dụng tối đa công nghệ Ajax vào xây dựng web. Điểm yếu của
nó chắc là kém rõ ràng hơn so với kiểu mà các PHP framwork hiện đang
làm.

Nhưng phải nói thêm là cái frame em làm này chủ yếu là để thực hiện
các nhiệm vụ về dữ liệu quan hệ, còn những hoạt động khác thì chưa
tình đến.

[toiyeuphp]

Đây là mẫu so sánh Push và Pull. Kết luật rút ra được:
Đây là cách thức của MVC ở phần code trên server chứ chưa đụng đến
client
View trong Pull chỉ có nhiệm vụ *chỉ điểm* chứ không lấy data hiện hữu
như Push
Vậy lợi ích là tiết kiệm vòng lặp, tiết kiệm bộ nhớ khi lưu tạm data
trên server vì chỉ lấy data 1 lần trong View chứ không lấy sẵn trong
Model rồi mới đưa ra View. Có lúc data đã được lưu trong memory ở
Model rồi lại lưu tiếp nữa trong Controller. Mặc dù vậy, cũng có tốn
chỗ để chứa ông *chỉ điểm*, nhưng so ra vẫn tiết kiệm hơn.

Push

All data is inserted into the template from the code via the Template
API before the template is rendered.

Here is a push based on this Smarty with MySQL Tutorial:

<TABLE BORDER="1" ALIGN="CENTER">
{section name=i loop=$phpmodule}
<list:LISTITEM>
<TR><TD>{$phpmodule[i].Name}</TD><TD>{$phpmodule[i].Description}</TD></
TR>
</list:LISTITEM>
{/section}
</TABLE>

The PHP code to bind the data to the template looks like this:

$List = array();
$result = mysql_query('SELECT Name, Description FROM phpmodules');
while ($row = mysql_fetch_array($result)) {
array_push($List, $row);
}

$smarty =& new Smarty;
$smarty->assign("phpmodule", $List);
$smarty->display('list.tpl');

Notice that the data is iterated over twice. Once when it is pulled
from the database and then again when the template goes to display it.
Pull

Bindings, callbacks, or events are used to allow the template API to
request the data it needs during the process of rendering.

The advantage of a pull style is that not all the data that it is
possible for a template to display need be constructed beforehand.
Thus if sections of the template are hidden or unused, the API can
skip calculating data for these sections. In a push style API, all the
data that the template could possibly display must be calculated ahead
of time and passed to the template before it is rendered.

WACT currently uses a mix of Push and Pull styles. Here is an example
of the Pull style with WACT:

<list:LIST name='ExampleList'>
<TABLE BORDER="1" ALIGN="CENTER">
<list:LISTITEM>
<TR><TD>{Name}</TD><TD>{Description}</TD></TR>
</list:LISTITEM>
</TABLE>
</list:LIST>

The corresponding code to bind a database query to this template:

$Page =& new Template('/list.html');
$List =& $Page->findChild('ExampleList');
$List->setDataSet(NewRecordSet('SELECT Name, Description FROM
phpmodules'));
$Page->display();

Notice NewRecordSet does not return an array containing all of the
records in the database, but instead returns an iterator that the
template can use to drive data access. In this example, the data is
iterated over only once. If this template fragment is hidden for some
reason, there will be no iteration over the data at all.