Với các Web Designer thì CSS Framework thật sự không thể thiếu trong công việc của họ. Nói đến 2 từ này người ta thường nhắc đến Blueprint, bởi nó quá phổ biến và cung cấp nhiều tính năng. Tuy nhiên, vẫn còn rất nhiều framework khác hữu ích không kém, chẳng hạn như 960 Grid System. Dưới đây là danh dách 8 CSS Framework mà bạn không nên bỏ qua !
Bạn đã và đang sử dụng framework nào ? Hãy chia sẻ cho mọi người biết nào ?
Các bài viết thảo luận nên dùng cái nào thì hay
Bài viết này giới thiệu sơ lược cấu trúc cơ bản của một phần mềm để giúp tăng năng suất của lập trình viên.
Các chủ đề sau sẽ được đề cập:
- Component-centric development
- Layers
Tác giả Nguyễn Minh Hải xin phép giữ trọn quyền tác giả đối với bài viết này. Tuy nhiên, độc giả có thể sang, chép, lưu truyền cho các bạn khác mà không cần phải xin phép tác giả (với điều kiện nguyên văn bài viết phải được giữ nguyên)
Software Architecture chưa bao giờ là lĩnh vực hấp dẫn cả, khi nào cũng khô như ngói. Tác giả chỉ mạn phép dùng ngôn ngữ “cây nhà lá vườn” để giúp các bạn mới học tiếp xúc thêm. Sai sót là không thể tránh khỏi. Và hy vọng các bạn sẽ không ngủ gục khi chỉ mới đọc xong trang một.
Read on at your own risk. You’ve been warned !!! J
Software Engineering phát triển rất nhanh, tuy nhiên vẫn còn ở giai đoạn chập chững tập đi mà thôi. Để thiết kế và phát triển một phần mềm tiêu tốn rất nhiều tài nguyên, nhưng sau đó thì không sử dụng lại được nữa. Lấy ví dụ, để viết chương trình quản lý kho, bạn sẽ phải xử lý SQL, tạo form, tạo report, security. Sau đó, khách hàng yêu cầu viết chương trình kế tóan thì bạn lại phải viết lại những yêu cầu trên… từ đầu. Nếu thiết kế xe ô tô cũng giống như thiết kế phần mềm thì khi thiết kế model 2006, bạn sẽ phải xây lại đường đi riêng, thiết kế lại bánh xe, đèn, vô lăng, vv…
Bạn nghĩ sao nếu như thiết kế một phần mềm mới cũng đơn giản như thiết kế một cái tivi? Chẳng hạn như bạn chỉ việc gắn bộ nguồn, mạch bắt sóng, mạch điều khiển, gắn đèn hình vào là xong. Bạn không cần phải đi thiết kế lại từng phần chi tiết tỉ mỉ làm gì cả. Giả sử bạn không thiết kế tivi nữa mà xoay sang thiết kế máy tính xách tay thì cũng thế, chỉ việc gắn bộ nguồn, đèn hình, mạch điều khiển. Điểm hay là ở chỗ một con transistor trong laptop hay tivi thì cũng y như nhau mà thôi.
Quay lại ví dụ viết chương trình quản lý kho, giả sử ta có một máy tính siêu thông minh thì chỉ việc bảo nó: gắn cục Security A101, cục Data 2.0, cục Web GUI 8.1 rồi dán nhãn My Big Soft vào đó rồi nó tự động làm hết mọi chuyện cho ta. Rất tiếc, đây chỉ là ước mơ, còn thực tế thì mỗi developer hằng ngày vẫn phải còng lưng viết code như những cái máy đến mờ mắt, viết đi viết lại, viết tới viết lui như một điệp khúc bất tận.
May thay, Component-centric đang ngày nhiều hơn và thông minh hơn. Nếu bạn là dân Java, hãy nghĩ đến Java Beans. Nếu bạn là dân .NET, hãy nghĩ đến Application Block, đến Web-parts. Hay đơn giản hơn, ai cũng đã gặp nhiều lần: UI controls (button, label, listbox, checkbox, …)
Một component không phải là một class, và component-centric cũng không phải là OOP (Object Oriented Programming). Class đơn thuần chỉ là gom nhiều code có cùng mục đích vào chung một chỗ. OOP là xem vấn đề như một hoặc nhiều đối tượng (có thuộc tính, có method) để phân lọai mối quan hệ của chúng. Còn component-centric có nghĩa là lập trình để mỗi phần mang tính độc lập, có thể thay thế, có thể tái sử dụng lại cho những vấn đề khác nhau.
Giả sử bây giờ bạn phải viết trò chơi Snake. (User điều khiển con rắn chạy ăn mồi, mỗi khi ăn được cục mồi thì con rắn dài ra thêm một đọan).
1/ Class: nếu bạn là dân “rồ” thì có lẽ bạn chỉ cần viết 1, cùng lắm là 2 class để viết trò chơi tí hon này.
2/ OOP: bạn sẽ bắt đầu viết các class: Snake, Food, Player.
3/ Component-centric: bạn chả viết gì cả J
Bạn sẽ ngồi phân tích xem đâu là điểm chung, đâu là điểm riêng, đâu là phần chi tiết chỉ áp dụng riêng cho trò chơi này, đâu là phần bạn có thể abstract nó. Có lẽ bạn sẽ thiết kế ra các component sau: Game Engine, Graphic Engine, Rule Engine, Resouces Manager, User Controller, vv…
Ah, như vậy sau khi thiết kế xong, trò Snake chỉ là sản phẩm phụ mà thôi. Với những component sẵn có, bạn dư sức có thể viết DOOM 2006.
Component-centric development và cao hơn nữa là software-manufacturing đang được đầu tư và phát triển rất nhiều. Nếu bạn có hứng thú, hãy tham khảo thêm:
- Microsoft Application Block
- Enterprise Java Bean
- Java Frameworks and Components: Accelerate Your Web Application Development – Michael Nash. Cambridge University Press 2003 ISBN: 0521520592
Nếu như Component là từng bộ phận nhỏ, đóng vai trò như một “black-box”, ta chỉ quan tâm tới chức năng của nó là chính, thì Layer lại giống như một bản mạch in gồm nhiều components đã được thiết kế sẵn. Lấy ví dụ như Graphics Card. Mở các máy PC hiện tại ra bạn sẽ thấy lọai card này. Điểm thú vị là bạn không phải “se duyên” với cái card ấy mãi mãi. Khi nào túi tiền rủng rỉnh, bạn có thể mua card khác mới hơn, nhanh hơn, xịn hơn để gắn vào và quên béng mất cái card cũ (hoặc rao bán chợ trời). Có khi nào bạn suy nghĩ lại và ngạc nhiên tại sao cái máy tính cũ kỹ đời 1998 của mình lại có khả năng chấp nhận card 3D đời 2006 không? Thật là một kỳ quan, bạn nhỉ?
Software cũng thế, nếu thiết kế chia một software ra thành nhiều layer thì sẽ tăng tính tái sử dụng, và quan trọng nhất là: chịu đựng được với thay đổi trong tương lai. Bạn hãy nghĩ thế này nhé: nếu Windows mà được thiết kế tốt hơn thì bạn đã có thể chơi game của Windows, chạy web server của Linux, và chạy chương trình đồ họa của Macintosh ngay trong hệ điều hành Windows.
Bài viết này sẽ đề cập đến 3 layer cơ bản nhất mà đa số các chương trình từ bé đến khổng lồ, từ bài tập của sinh viên đến game online kinh phí hàng trăm triệu đô đều cần phải có.
Nếu bạn biết “Select * from Products Where CustID = @ID” nghĩa là gì nhưng bạn không cần phải dùng đến nó mỗi ngày thì bạn may mắn quá, bạn có thể bỏ qua phần này.
Nếu bạn không những biết mà còn thuộc nằm lòng đến 80% T-SQL 92, hoặc bạn nằm mơ cũng nghĩ đến SQL, đến StoreProc, đến Triggers, thì bạn rất cần phải dùng đến DAL. Có lẽ 90% developers, nhất là ở Việt Nam trong thời điểm hiện tại, rơi vào trường hợp này.
Trước hết, hãy nói Data Access Object là gì đã. Khi lập trình cơ sở dữ liệu, bạn phải lặp đi lặp lại thao tác sau:-
- Create connection
- Create SQL command
- Execute SQL
- Process results
Chán quá, bugs nhiều quá. Database bạn dùng là relational, mọi thứ đều trong table, table, table. Trong khi đó, bạn lại thích lập trình OOP cơ. Thế là bằng cách này hay cách khác, cho dù bạn biết hay không biết, bạn sẽ quay sang làm theo kiểu sau: định nghĩa class chuyên nói chuyện với database. Lấy ví dụ như class sau:
Class ProductDAO
{
Connection GetConnection();
bool Insert(int ID, string Name);
DataSet GetAllProducts();
DataSet GetProductByName(string Name);
Bool Delete(int ID);
}
Phương pháp bạn vừa làm chính là Data Access Object. Bạn có thể viết tay, bạn cũng có thể dùng các công cụ như CodeSmith để làm giùm bạn. Xin chúc mừng !!! Bạn đã đỡ khổ hơn trước nhiều rồi đấy.
Nhưng mà, cũng xin… chia buồn với bạn luôn. Bạn nghĩ sao nếu database bên dưới thay đổi? Bạn sẽ dùng CodeSmith để generate lại ư? Thế mấy cái business logic của bạn khi generate lại đi tong hết thì sao? Thế lỡ năm sau CodeSmith dẹp tiệm thì sao, bạn phải sửa lại bằng tay à? Thế lỡ database không phải của bạn, mà bạn phải integrate vào database bự xự có sẵn của khách hàng thì sao? Chua đấy bạn ạ. Chưa kể là dùng Data Access Object làm tăng số lượng class lên rất nhiều (cứ mỗi table trong database cần ít nhất 1 class, thậm chí có thể là 3, 4 classes). Mỗi class cần ít nhất 4 method (Create, Read, Update, Delete). Chưa kể là mỗi kiểu select khác nhau lại phải viết method mới. Điều này đồng nghĩa với việc testing cũng tăng lên đến chóng mặt.
Bạn nghĩ sao nếu bạn chỉ cần định nghĩa một class thế này:
Class Product
{
Int ID;
String Name;
String Description;
}
Xong, chỉ có thế thôi !!! Nếu cần thêm sản phẩm mới vào database thì làm như sau:
Product p = new Product();
p.Name = “ Some product”;
Database.AddNew(p);
Nếu cần query một sản phẩm thì chỉ cần thế này:
Product p = Database.Get(typeof(Product), Name = “ProductA”);
Rất đơn giản, phải không bạn? Cái đẹp là ở chỗ nếu có thêm nhiều table nữa thì cũng thế, bạn chả phải viết thêm nhiều methods chi cho mệt cả, chỉ định nghĩa class của bạn ở mức đơn giản nhất. Và khóai nhất là bạn không cần phải viết thêm một mớ test để kiểm tra việc truy xuất class đó.
Đây chính là chức năng chính của Data Access Layer.
Nếu thích, bạn có thể tham khảo:
- Data Access Layer trong Microsoft Application Block
- O/R Mapping (Object-to-Relational Mapping): Wilson O/R for .NET, ORM.Net, Object Space
- Java Persistence for Relational Databases – Richard Sperko. Apress 2003 – ISBN:1590590716
Lưu ý: Persistence Layer về cơ bản có cùng tính năng như Data Access Layer. Tuy nhiên, Persistence Layer có khái niệm và cách thức thực hiện khác với DAL một tí, mỗi lọai có cái hay và cái dở riêng.
Business Object rất thú vị ở chỗ chương trình nào cũng cần có nó, nhưng lại chẳng có framework hay standard chuẩn nào cho bạn cả. Đơn giản là vì business object thay đổi xòanh xọach tùy theo yêu cầu cụ thể của từng business khác nhau.
Trong đa số trường hợp, Business Object sẽ được thiết kế rất gần giống với Data Object (chỉ chứa dữ liệu hoặc nói chuyện với cơ sở dữ liệu), chỉ khác ở chỗ thêm vào đó một ít validation rule và business rule (ví dụ: nếu tài khỏan chỉ có 1.000 thì không cho phép rút 1 triệu đồng).
Tuy nhiên, có những vấn đề lặp đi lặp lại mà business nào cũng phải gặp, chẳng hạn như: transaction, distribution, validation. Khi thiết kế Business Object, một architect bao giờ cũng đau đầu với những câu hỏi chẳng hạn như: nên stored proc hay không? Nên validate ở đâu (trong DBMS, trong server, hay trong client)? Object của tui như thế có scalable không, có nhanh hay không? Vv.. và vv…
Business Object Layer là một lớp abstraction cho phép giải quyết những vấn đề thường gặp khi thiết kế business logic. Với một framework tốt, Business Object Layer đóng vai trò rất quan trọng vì nó là “sợi chỉ đỏ xuyên suốt các layers”.
Vì nhiệm vụ của Business Object rất đa dạng và cũng có nhiều khó khăn khác nhau nên Business Object Layer thường được đóng gói với tên gọi Application Frameworks. Lập trình viên bình thường và những project vừa và nhỏ ít có cơ hội tiếp xúc. Những framework thương mại chủ yếu dành cho các project lớn và đòi hỏi phải học chuyên sâu. Những framework này cũng thường “overkill” với project nhỏ. Tuy nhiên, nếu đơn giản hóa vấn đề thì khi bạn tự viết một Business Object Layer cho bản thân sẽ tăng năng suất của bạn lên rất cao.
Tài liệu tham khảo:
C- C# Expert Business Object
(Cuốn này hơi khó kiếm, nhưng là sách quý nên có)
Hồi lúc trước, mình là tín đồ của nàng Athena xinh đẹp (nói cách khác là dân ghiền Delphi). Khi chuyển sang C#, mình đã thất vọng tràn trề. Lẽ ra trong Delphi thiết kế một form có master/detail view chỉ mất 1 phút thì trong C#, mình phải mất 2 trang code (hồi lúc mới học thì mất cả tuần vì không hiểu làm sao để sử dụng cái datagrid). Sau đó, chuyển sang ASP.NET thì … càng đau khổ hơn nữa.
Tại sao ta lại phải khổ thế nhỉ? Viết form cực kỳ chua. (Hỏi mấy em lập trình Java với AWT thì biết). Với các ngôn ngữ hiện đại ngày nay thì ta có designer làm sẵn cho, chỉ việc kéo thả bụp bụp là xong. Các bộ controls thương mại hiện giờ có rất nhiều, mỗi người một vẻ. Với những bộ lớn chẳng hạn như của ComponentOne, Janus System, họ gắn luôn mác Presentation Layer vào sản phẩm của họ. Có lý phần nào vì đó là những component phục vụ cho việc trình bày thông tin.
Nhưng mà, vẫn còn nhiều vấn đề tồn đọng:
1/ Lệ thuộc vào control nhất định. Hãy quên chuyện thay thế grid của Winform bằng grid của Developer Express mà không cần phải sửa lại code đi nhé. Nhiều khi không chỉ sửa code mà bạn cần phải mướn developer khác để sử dụng UI controls mới.
2/ Không có chuẩn. Mỗi bộ controls là một framework mới cần phải học và không tương thích gì với nhau cả. Đừng mơ có chuyện viết code năm nay, 2 năm sau quay lại thay giao diện cái rẹt.
3/ Logic code và UI code quyện lẫn vào nhau. Visual Studio 2005 cố gắng giúp (lừa) bạn tránh chuyện này bằng partial class, chia code thành 2 file (bắt chước asp.net, file aspx riêng, file code-behind riêng)
4/ Visual rất luộm thuộm. Bạn nghĩ sao nếu bạn viết chương trình đồng hồ Analog (có kim giờ, phút, giây quay vòng vòng), nhưng ngày mai bạn thích đồng hồ Digital (chỉ hiển thị số). Bạn có thể nào giữ y nguyên logic code, chỉ cần thay visual elements cái rẹt trong 5 giây không? Quên chuyện đó đi.
5/ Data-binding: Rất phiền. Những control sẵn có khiến cho bạn trở thành gà công nghiệp và lệ thuộc vào nó. Điều đáng buồn là khi bạn cần binding phức tạp một tí thì vẫn cứ phải “chân lấm tay bùn”, quay trở lại viết code từng dòng một, xử lý event từng chỗ một.
Những năm gần đây xu hướng Declarative Programming gây được nhiều sự chú ý. Lấy ví dụ như thay vì viết code tạo form như sau:
Button b = new Button();
b.SetBounds(100,100,50,25);
b.Text = “Click me”;
b.Click += new EventHandler(b_OnClick);
Thì ta có thể tạo một file XML như sau:
<Button Location=”100,100” Size=”50,25”>Click me</Button>
Rất giống lập trình web, phải không bạn? Vâng, web chính là thuở ban đầu của declarative programming. Bạn thử tưởng tượng cũng một file XML đó, bạn có thể dùng làm windows application, bạn có thể dùng làm webform, có thể dùng cho Flash, có thể dùng cho Macintosh thì sao?
Có mà nằm mơ !
Hẳn bạn sẽ thốt lên như thế. Vâng, rất tiếc rằng ở thời điểm hiện tại chưa có Presentation Layer nào thực hiện được mơ ước “write once, display anywhere”. Tuy nhiên, ít ra thì bạn không còn phải viết code từng dòng bằng tay nữa, bạn có thể nhờ Presentation Layer để tự validate inputs, tự generate forms, tự layout, vv…
Để xem thêm về lĩnh vực này, bạn hãy research các chủ đề sau:- - Avalon, MyXaml, XAML, XAMLon
- Flex
- XUL
Design patterns nôm na ra là cách thức giải quyết cho những vấn đề thường gặp. Điều đáng buồn là các sách về design patterns khô như ngói, nhạt như vôi. Nhưng tin vui: design pattern là công cụ sẽ giúp bạn tăng lương lên gấp đôi (hoặc gấp trăm lần). Đơn giản vì design pattern chính là kinh nghiệm xương máu của những architect đi trước đúc kết ra được. Khi bạn học design pattern, bạn sẽ có những kinh nghiệm vượt trước năng lực của mình.
Tài liệu để đọc về design pattern hiện có rất nhiều. Mình chỉ mạn phép góp ý với các bạn một câu khi học về lĩnh vực này: “hãy nắm lấy ý tưởng là chính, đừng chú trọng vào code”. Nếu bạn chỉ nhìn vào code ví dụ, bạn sẽ dễ bị “tẩu hỏa nhập ma”, sẽ bị lệ thuộc vào code, nhìn thấy cái nào cũng na ná nhau, và tệ hại nhất là chẳng biết áp dụng vào cho cái gì khác ngòai ví dụ ra.
Tài liệu để tham khảo:
- C
- C# Design Pattern – A tutorial
- Software Architecture Design Patterns in Java – Partha Kuchana
Về layers và thiết kế ở mức cao một tí, đọc các sách sau:-
- Enterprise Solution Patterns Using Microsoft.NET version 2.0 – MS Press
- .NET Patterns: Architecture, Design, and Process – Christian Thilmany – Addison Wesley ISBN: 0-32-113002-2
Viết bài này mình cứ sợ “múa rìu qua mắt thợ” bởi vì người tài giỏi của Việt Nam cũng có rất nhiều. Tuy nhiên, có nhiều bạn cứ nói mình mãi là hãy viết đi, và qua thực tế đi dạy học được một thời gian, mình thấy những bạn sinh viên mới ra trường biết rất ít về thiết kế phần mềm, dẫn đến hậu quả là các bạn ấy đa phần giống như gà công nghiệp, và hiển nhiên code của các bạn cũng như một tô mì ăn liền: ăn đỡ đói thì được, còn ăn nhiều thì hơi ngán.
Hy vọng bài viết này sẽ giúp các bạn có được một số gợi ý để đào sâu nghiên cứu thêm. Chúc các bạn luôn giữ niềm đam mê lập trình của mình.
- Nguyễn Minh Hải
Muốn hiểu tại sao người ta chia một phần mềm có lưu trữ data ra thành 3 lớp (3-tier), thì phải nhìn từ lịch sử lập trình, nghĩa là tại sao người ta cần chia một phần mềm ra thành nhiều phần khác nhau. Rồi những phần đó tại sao lại được xếp nhóm vào 3 lớp chính là Presentation, Business logics và Data.
Lý do về việc tại sao phải chia phần mềm thành nhiều phần để viết, ở đây các bác của em toàn là cao thủ lập trình, chắc em không cần phải nhắc lại. Thế rồi giải thích tại sao lại chia phần mềm thành ba lớp chính là Presentation, Business logics và Data, thì cũng đơn giản như giải thích tại sao bánh xe hình tròn, tại sao TCP/IP có 4 lớp và OSI có 7 lớp.
Ngắn gọn là sau nhiều chục năm thử và sai, kinh nghiệm cho người ta thấy rằng chia phần mềm thành 3 tier chính như thế có tác dụng tốt nhất cho những việc như sau đây:
- Phát triển phần mềm: Có tính chuyên nghiệp hóa, có thể chia cho nhiều nhóm được đào tạo nhiều kỹ năng khác nhau, từ thiết kế mỹ thuật cho đến lập trình đến tổ chức database.
- Bảo trì: Với các lớp được phân chia theo như đã nói, thì các thành phần của một hệ thống dễ được thay đổi, nhưng sự thay đổi có thể được cô lập trong từng lớp, hoặc chỉ ảnh hưởng đến lớp ngay gần kề của nó, chứ không phát tán náo loạn trong cả chương trình.
- Mở rộng: Với các lớp được chia theo 3-tier như đã nói, việc thêm chức năng vào cho từng lớp sẽ dễ dàng hơn là phân chia theo cách khác.
Còn tại sao, các bác cứ thử chia theo cách khác, ví dụ không thành Presentation, Business và Data, mà thành cái quái gì đấy, rồi mở rộng, thay đổi các thành phần thì chắc là khó hơn.
He..he..mà cũng chưa chắc, vì chân lý là cái lý có chân, tức là nó chạy đi chạy lại theo thời gian.
Sau khi đã chia thành 3 tier chính như đã nói, trong mỗi tier người ta có thể chia thành nhiều layer. Nói chung là trong software, người ta dung từ layer và tier interchangeable, tiếng Việt lại toàn dịch là lớp. Nói là nhiều tier hay nhiều layer, nói chung không sai. Nhưng nhóm các layer cùng chức năng tương tự lại, thì bao giờ cũng gồm ba nhóm chính là Presentation – Business logics – Data.
Còn MVC Design pattern là một design pattern dành riêng cho Presentation layer, chứ không phải là cách chia toản bộ một application ra thành 3 tier là Model – View – Controller.
Trong đó, View là các display objects, ví dụ như window, frame, dialog, panel hoặc Web page (HTML page, HTML template, XML template, JSP, ASP, ASPX, PHP template, Ruby template …), chỉ dùng để hiển thị thông tin, các visual objects để tương tác với người dùng …
Model là các in-memory objects, chứa thông tin về các business objects mà hệ thống chương trình sử dụng.
Controller là phần xử lý logic. Logic này bao gồm việc thu nhận yêu cầu từ người dùng, xử lý, tính toán theo yêu cầu, tìm kiếm, khởi tạo các in-memory objects (các model), xử lý các models, và lựa chọn view cần thiết, gửi thông tin đến view, và gửi view vào mặt user.
Em của các bác có một bài viết về implementation cho MVC Design Pattern trong Java ở đây:
http://www.hanoian.com/index.php?opt…38&Itemi d=44
Trong đấy em có nói qua về MVC model 1, MVC model 2 trong J2EE kinh điển, và có đề nghị một giải pháp về mixed MVC, có giải thích lý do, và cung cấp code.
Các bác thích thì vào đọc.
MVC chỉ là sự chia nhỏ các thành phần có tương tác với user, nghĩa là các thành phần trong Presentation layer..
Các Model có thể được tạo ra từ các nguồn khác nhau.
- Các thông tin do user gõ vào. Ví dụ như các bác viết một chương trình giải phương trình bậc nhất ax + b = 0.
Như vậy các bác có thể tạo ra một trang web có 2 cái text box, một cái nhập a, một cái nhập b, và một nút bấm “Tính nghiệm”, hoặc một cái stand-alone GUI bằng VB, bằng VC ++ hoặc bằng whateverthehell các bác thích, có chỗ để nhập nghiệm. Đấy gọi là view.
Còn cái mà các bác định nghĩa là “float a, b, x” hoặc “Dim a, b, x As con khỉ gì đấy” thì chính là model, in-memory object để lưu data.
Còn controller có thể là một class riêng biệt để tính nghiệm. Method của class này được gọi trong phần xử lý event hay Submit của cái nút bấm. Hoặc nhiều khi các bác không thích, thì viết luôn phần tính nghiệm trong cái method xử lý event của cái nút bấm.
Như vậy, trong trường hợp này, phần mềm không có Data tier.
- Có trường hợp thì model là in-memory copies của objects trong database, hoặc của e-mail trong mail server, hoặc của objects trong LDAP repository, hoặc trong file trên đĩa cứng …
Trong trường hợp các ứng dụng đơn giản nhất, thì phần truy cập data để khởi tạo in-memory objects sẽ được viết luôn trong controller.
Như thế, ranh giới giữa Presentation layer và Business logic trở nên mờ nhạt. Điều này không hoàn toàn có nghĩa là xấu, nếu như ứng dụng của các bác đủ đơn giản.
Nhưng khi logic để access data trở nên phức tạp, thì việc truy cập data sẽ được tách thành một (hoặc một nhóm ) component riêng, bên ngoài Controller. Như thế sẽ hình thành một layer gọi là Data access layer ở trong Business tier.
Ngoài ra, việc xử lý, tính toán thuần túy trên models, không liên quan gì đến logic của việc trình bày thông tin trên màn hình, cũng có thể được tách riêng ra, thành Business computational layer, nằm trong Business tier.
Như vậy thì trong Controller chỉ còn logic liên quan đến presentation, ví dụ như định dạng layout, chọn view, định dạng thông tin của object được in ra…
Rồi những vấn đề như login (Authentication) và access control (Authorization) cùng với các dịch vụ về Data Encryption và Data Decryption cũng có thể được tách riêng ra thành security layer.
Còn nhiều thứ tương tự.
Như vậy chúng ta có thể thấy là chia phần mềm thành các tier như đã nói, thì về căn bản, các tier có thể được xếp vào 3 nhóm chính là Presentation, Business logics và Data.
Trong từng tier, có thể chia thành nhiều layer khác nhau. Như vậy mới có cái gọi là kiến trúc n-tier, multi-tier hay là n-layer, multi-layer …
Nhưng chia phần mềm theo 3-tier như đã trình bày, chỉ là một cách chia, cách này gọi là horizontal slice. Cho đến nay, số đông trong ngành kiến trúc phần mềm vẫn đồng ý đây là cách chia tốt nhất.
Tuy nhiên, như em đã nói đâu đó ở trên, chân lý là cái lý có chân. Vì thế hôm qua thầy giáo các bác, hoặc sách của Tây rậm râu và Tây trán hói nói là 3-tier là tốt nhất, hôm nay rất có thể cái lý nó không còn ở chỗ đấy nữa.
Comes in the picture: Vertical slice and SOA
Khi khác em lại viết tiếp về vertical slice và SOA.
Rồi còn chuyện MVC bị dùng sai trong nhiều software project ở Mỹ như thế nào, nhiều khi cũng rất nực cười và thê thảm.
Chau Hong Linh (http://connekgroup.net/forum/showthread.php?t=1615)
1. Miễn phí và có thể được sử dụng cho mục đích thương mại
Có rất nhiều thứ miễn phí dành cho bạn:
- Công cụ miễn phí
- Dịch vụ host miễn phí trên Popfly
- Các bài hướng dẫn từ BDLC
- Các control và ebook
- Các đoạn code mẫu trong Coding4Fun Development Kit
- Bộ công cụ P2P, và
- Bộ công cụ C++ Game Development
2. LINQ và các cải tiến ngôn ngữ
Visual Studio Express 2008 hỗ trợ đầy đủ LINQ (Language INtergrated Query) cho phép việc thực hiện ngôn ngữ truy vấn (tương tự như SQL) trực tiếp trong ngôn ngữ Visual Basic và C#. Điều này có nghĩa là bạn có thể truy vấn một cơ sở dữ liệu dạng XML chẳng hạn như các RSS feeds hay các đối tượng bên trong bộ nhớ bằng cách sử dụng một cú pháp đơn giản. Đi cùng với LINQ là một số những cải tiến trong ngôn ngữ giúp đơn giản hoá công việc với các kiểu dữ liệu của .NET và điều này sẽ được thấy rõ khi ta làm việc với LINQ.
3. Nhiều nội dung học miễn phí
Beginner Developer Learning Center (BDLC) có các đoạn video cho 4 sản phẩm của Express Edition cũng như các bài tutorial về LINQ, WPF,…
4. Bộ thiết kế web và công cụ Javascript mới
Được xây dựng dựa trên các engine của Expression Web, Visual Web Developer Express designer bao gồm một design view mạnh với các tính năng mới như Split View để xem cả HTML code và designer, cửa sổ CSS Styles và Properties để thiết kế, xem trước, và apply các kiểu khác nhau.
Công cụ Javascript có cải tiến hơn về Intellisense, suy luận kiểu dữ liệu, IntelliSense tham số, hỗ trợ các Ajax control, bộ debug được cải tiến với visualizers cho các dữ liệu của Javascript,…
5. Windows Presentation Foundation
6. Bộ công cụ phát triển Game cho C++
7. Hỗ trợ ASP.NET AJAX và các Ajax Control
Trong Visual Web Developer Express 2008 có sẵn ASP.NET AJAX giúp bạn có thể dễ dàng thực hiện công việc cập nhật partial-page (cập nhật bằng cách nhận dữ liệu động từ server mà không cần phải load lại trang) chỉ với 1 thao tác là add control UpdatePanel vào. Hơn nữa, bạn có thể sử dụng lại tất cả bộ ASP.NET AJAX Control Toolkit để trang web có các tính năng RAD AJAX như animation, đổ bóng (drop shadows), góc bo tròn (rounded corner),…
8. Nâng cao hiệu suất hoạt động
Trong phiên bản này nhóm phát triển đã cố gắng tăng hiệu suất hoạt động cho các công việc như Visual Basic background compiler hay C# IntelliSense. Bạn sẽ cảm nhận sự khác biệt khi phát triển các dự án lớn.
9. Killer Content
Bộ Coding4Fun Developer Toolkit cung cấp nhiều sample và resource hỗ trợ Windows Vista như Telephony, Mail, Calendar,…
10. Những “đồ chơi” miễn phí
Khi bạn register bộ Visual Studio Express, bạn sẽ nhận được
- Các control miễn phí như Telerik Rad Ribbon Bar để xây dựng các ứng dụng có giao diện Office 2007,…
- Các hình ảnh, icon miễn phí
- Ebook miễn phí
- Giảm giá
Sau khi đăng ký xong hãy đến trang http://connect.microsoft.com để download
(nguồn : http://ciren.vn/forums/showpost.php?p=2756&postcount=5)
Ta dùng lệnh sau trong cửa sổ của DOS
trong đó X là tên ổ đĩa
1. Những yêu cầu với 1 chương trình máy tính
Đầu tiên ta cần biết lập trình là viết ra những chương trình nhằm giúp máy tính giải quyết những bài toán, những yêu cầu nào đó trong thực tế cho ta. Vì vậy có 1 số yêu cầu nhất định cho việc viết chương trình:
+Đúng đắn: chương trình phải đáp ứng được những yêu cầu được đặt ra.
+Chính xác
+Tin cậy: bảo đảm cùng 1 dữ liệu nhập vào thì kết quả trả ra luôn luôn giống nhau
+Tổng quát: người lập trình viên phải có khả năng nhìn thấy tất cả mọi khả năng có thể của dữ liệu nhập vào và chương trình phải làm việc tốt được với mọi dữ liệu nhập vào.
+An toàn: chương trình phải làm việc tốt ngay cả trong những điều kiện bất thường xảy ra, hạn chế việc chương trình bị “chết” trong quá trình chạy vì nhiều nguyên nhân như dữ liệu nhập vào không phù hợp, lỗi truy cập…vv… (hình như việc này ngay cả Microsoft cũng…ko làm được vì Widows cứ bị hư hoài à…).
+Hiệu quả: Chương trình phải tiết kiệm tài nguyên ở mức thấp nhất có thể, chạy nhanh nhất ở mức có thể…
+Dễ nâng cấp, sửa chữa.
2.Thiết kế chương trình:
a. Các xu hướng thiết kế:
Hiện nay có 2 xu hướng chính được chọn lựa trong việc thiết kế chương trình máy tính đó là : hướng thủ tục và hướng đối tượng
a.1.Hướng thủ tục(MP):
Thông qua 1 quá trình phân tích nhất định, lập trình viên sẽ tách bài toán hay yêu cầu ban đầu thành những bài toán con, yêu cầu con đơn giản hơn và giải quyết từng thứ 1. Việc này sẽ giúp bạn thực hiện được các bài toán phức tạp 1 cách dễ dàng. Bởi vì viết tổng thể cả 1 bài toán phức tạp là 1 việc làm rất khó và gần như Mission Impossible, nhưng chia nhỏ nó ra thành từng phần nhỏ hơn để giải quyết rùi gắn từng phần riêng đó lại là lựa chọn dễ dàng và khôn ngoan hơn. Việc này còn giúp cho chương trình của bạn dễ đọc, dễ bảo quản và dễ sửa chữa hơn.
Vd: yêu cầu đặt ra là bạn phải viết 1 chương trình dọc dữ liệu từ 1 file chứa các thông tin về số nhân viên, thông tin của từng nhân viên của 1 công ty, xử lí và trả lại thông tin về lương sẽ trả tháng này của từng nhân viên.
Như vậy nếu bạn để y nguyên như vậy mà làm sẽ rất khó và khi có sai sót bạn sẽ rất khó dò lỗi trong 1 khối chương trình gộp chung như vậy. Vì vậy bạn sẽ tách quá chương trình ra 1 số quá trình đơn giản hơn như sau:
Xử lí việc đọc file
Xứ lí thông tin đọc được từ file
Xử lí việc thông báo kết quả.
Từ các quá trình này bạn có thể tách thêm các quá trình con nữa nếu cần.
Như vậy khi xảy ra lỗi trong lập trình thì việc tìm lỗi và sữ chữa sẽ dễ dàng hơn cho bạn. Chẳng hạn khi lỗi thuộc về việc đọc file thì bạn chỉ cần dò tìm nó trong đoạn thủ tục bạn viết dùng để đọc file.
a.2.Hướng đối tượng(OOP): đây là 1 hướng thiết kế mới và gần với thực tế hơn phương pháp hướng thủ tục nhưng đương nhiên đòi hỏi ở bạn nhiều việc để làm và suy nghĩ hơn. 1 cách cơ bản mà nói thì hướng đối tượng nhìn vấn đề với 1 “con mắt khác” so với hướng thủ tục.
Khác như thế nào???
Nếu như ở hướng thủ tục bạn nhìn chương trình như “1 đống những công việc nhỏ cần phải làm tuần tự”. Thì khác 1 chút ở hướng đối tượng bạn nhìn theo hướng “1 đống những dữ liệu cần được tách riêng và xử lí” (đây là cảm nhận và cách hiểu riêng của snow về 2 hướng lập trình này…).
Vậy tại sao nói hướng đối tượng gần với thực tế hơn hướng thủ tục???
Đơn giản là vì trong thực tế mọi thứ tồn tại vốn dưới dạng các đối tượng (dữ liệu) khác nhau và các đối tượng đó tương tác với nhau chứ ko phải là các thủ tục.
Vd: bạn có thể hình dung như thế này. Cũng với ví dụ tính lương ở trên.
+Bây giờ giả sử tất cả các nhân viên đó đều thuộc về 1 công ty và có những chức vụ khác nhau. Như vậy nếu nhìn theo hướng thủ tục bạn sẽ chỉ thấy việc phải xử lí riêng cho từng loại nhân viên thuộc từng chức vụ 1 và việc này hơi “rối mù“ 1 chút trong chương trình và dễ gây nhầm lẫn cũng như sẽ khó cho việc sửa chữa, nâng cấp về sau nếu như xuất hiện thêm những chức vụ mới.
+Nhưng nếu bạn nhìn theo hướng đối tượng bạn sẽ thấy rằng đầu tiên ở đây có chung 1 loại đối tượng lớn nhất là “nhân viên”. Tiếp theo từ “nhân viên” ta có thể tách ra những đối tượng con của nó là “công nhân”, “trưởng phong”, “thư kí”, “giám đốc”, mỗi 1 đối tượng con sẽ có chung các đặc điểm của đối tượng cha và có riêng các đặc tính riêng của nó. Như vậy khi có thêm chức vụ thì bạn chỉ đơn giản thêm vào 1 đối tượng con mới chứ ko cần sửa lại đoạn mã đã viết ban đầu.
Nhưng bạn phải hiểu đối tượng trong hướng đối tượng ko chỉ đơn giản là “dữ liệu” mà mỗi đối tượng ngoài dữ liệu còn mang trong nó những thủ tục, hành vi của riêng đối tượng đó và đối tượng tương tác với các đối tượng khác thông qua các hành vi này. Và các đối tượng giống nhau sẽ có cùng những hành vi giống nhau. Đây là tính đóng gói của hướng đối tượng.
Ngoài ra hướng đối tượng còn có tính thừa kế nghĩa là tất cả những kiểu đối tượng con dẫn xuất từ cùng 1 kiểu đối tượng cha sẽ được thừa kế những “đặc tính” di truyền của cha (về dữ liệu cũng như hành vi…).
Một tính chất quan trọng khác của hướng đối tượng là tính đa hình, nghĩa là cùng 1 hành vi nhưng đối tượng sẽ có cách “xử sự” khác nhau với từng loại đối tượng khác nhau tuỳ theo định nghĩa của bạn về hành vi của đối tượng đối với từng loại đối tượng khác nhau…
b.Các phương pháp thiết kế:
Ở đây cũng có 2 phương pháp thiết kế chính là từ trên xuống (Top-down) và từ dưới lên (Bottom-up)
b.1.Top-down:
Đây là phương pháp thiết kế mang tính đi sâu vào tổng quát trước. Ở từng tầng của phương pháp thiết kế này chức năng tổng quát nhất được đem ra làm tên gọi, sau đó bạn phát triển những tầng tiếp theo nhỏ hơn của chức năng đó. Và cứ tiếp tục phân tầng như vậy cho tới khi các chức năng đã được đơn giản ở mức có thể thực hiện dễ dàng và hiệu quả.
b.2.Bottom-up:
Ngược lại với kiểu thiết kế top-down là kiểu bottom-up. Kiểu này được sử dụng chủ yếu khi bạn cần xây dựng chương trình từ những thứ đã có sẵn. Như vậy bạn chỉ cần tìm các thành phần cần thiết từ những thứ đã có. Một ví dụ đơn giản là khi bạn sử dụng các hàm đã có sẵn và được hỗ trợ của ngôn ngữ lập trình để xây dựng 1 ứng dụng đơn giản nào đó.
3.Các cấu trúc điều khiển cơ bản:
Dù chương trình của bạn có được xây dựng phức tạp như thế nào, có ứng dụng những giải thuật cao siêu tới đâu thì thực chất 2 thành phần cơ bản nhất xây dựng ra chúng vẫn chỉ là dữ liệu và các cấu trúc điều khiển. ở đây snow nói về các cấu trúc điều khiển cơ bản:
+Cấu trúc điều khiển tuần tự:
các toán tử, hàm, câu lệnh, dữ liệu được xử lí theo nguyên tắc tuần tự: trái sang phải, trên xuống dưới. Bạn phải nắm rõ sự tuần tự này và cả các thay đổi của dữ liệu trong thứ tự làm việc của chương trình nếu muốn đảm bảo chương trình sẽ chạy đúng.
+Cấu trúc điều kiện:
Bao gồm những toán tử, hàm, câu lệnh, dữ liệu chỉ được thực hiện hoặc xử lí khi 1 điều kiện nào đó được thỏa mãn.
+Cấu trúc lặp:
Gồm những toán tử, hàm, câu lệnh, dữ liện sẽ được xử lí lặp lại 1 số hữu hạn lần nào đó. Bạn phải chú ý khi sử dụng cấu trúc lặp để tránh tạo ra những cấu trúc lặp vô hạn sẽ dẫn đến việc treo máy. Vì vậy yêu cầu đầu tiên khi sử dụng cấu trúc lặp là điều kiện dừng của vòng lặp phải đúng đắn. Bạn còn phải lưu ý tính nhớ và sự thay đổi của dữ liệu trong vòng lặp để đảm bảo cho chương trình chạy đúng.
+Ngoài 3 cấu trúc cơ bản trên còn 1 kiểu lập trình rất cần thiết cho 1 số bài toán, đó là kiểu đệ qui. Đôi khi đây là “điều không thể tránh khỏi” khi bạn “đụng” vào những bài toán có bạn chất là đệ qui.
1 thủ tục đệ qui sẽ gọi lại bản thân nó tại 1 nơi nào đó bên trong thủ tục đó nếu 1 điều kiện dừng nào đó ko được thoả. Cũng giống như cấu trúc lặp, khi sử dụng đệ qui bạn phải đảm bảo điều kiện dừng cho nó. Nhưng bạn cần lưu ý là đệ qui sẽ chiếm 1 số khá lớn tài nguyên bộ nhớ do mỗi 1 lần đệ qui, các mã lệnh sẽ được “quăng” vào stack của bộ nhớ và lưu lại đó cho tới khi được xử lí. Như vậy đệ qui càng nhiều lần thì bộ nhớ sẽ “nặng” và ảnh hưởng tới hiệu quả của các chương trình khác. Trong 1 số trường hợp bạn có thể khử đệ qui bằng cách sử dụng các vòng lặp, stack hoặc queue…
1 ví dụ đơn giản về đệ qui trên C:
Chẳng hạn để tính 1 giai thừa n!, bạn có thể sử dụng 1 hàm đệ qui như sau:
int Giai_thua(int n)
{
if(n==1)
return 1;
return n*Giai_thua(n-1);
}
Nhưng cũng có thể sử dụng vòng lặp để giải quyết:
int Giai_thua(int n)
{
int result=1;
for(int i=2; i<=n; i++)
result *= i
return result;
}
4. Tổng quát về trình biên dịch và thông dịch của ngôn ngữ lập trình:
Ở đây snow chỉ nói sơ sơ những gì snow hiểu về trình biên dịch và thông dịch để giúp các bạn khỏi thắc mắc xem “nó làm ăn ra sao???”. Và đây cũng được coi là những hiểu biết sơ đẳng nhất mà bạn cần biết khi lập trình:
Như snow đã từng đề cập ở trên, việc lập trình ngày nay ko phải là cái kiểu ngồi dịch từng mã nhị phân như “cái thuở ban đầu lưu luyến ấy” nữa. Ngày nay các lập trình viên tạo ra các chương trình bằng việc lập trình bằng 1 ngôn ngữ nào đó và đem biên dịch bằng trình biên dịch của ngôn ngữ đó trước khi chạy chương trình, hoặc vừa chạy vừa dịch(chạy tới đâu dịch tới đó) nếu là trình thông dịch.
2 chương trình trên thực chất có thể coi là trung gian giao tiếp giữa người lập trình viên và máy tính. Hiểu nó bạn sẽ hiểu “Ê, tại sao tui viết cái lệnh toàn tiếng Anh hông hà mà mấy cái máy nó hiểu hay vậy???”. Thiệt ra thì máy đâu có hiểu mấy cái “tiếng Anh nửa mùa” mà bạn viết. Nó chỉ hiểu mã nhị phân 0,1 của những gì bạn viết ra đã được trình biên dịch hoặc thông dịch dịch lại cho nó “nghe” thôi. Nhưng giữa 2 chương trình thông dịch và biên dịch có những khác biệt nhất định dù chúng có cùng nhiệm vụ là “dịch” lại cho máy “nghe” những gì bạn “nói” với nó.
4.1 Trình biên dịch:
Toàn bộ mã chương trình mà bạn viết sẽ được trình này dịch ra hợp ngữ (assembly) để chuyển thành chỉ thị máy. Trong quá trình này có thể bao gồm quá trình tiền xử lí, biên dịch từng đoạn nhỏ của chương trình, kiểm tra lỗi, kiểm tra kiểu của các biến…, lắp ráp lại thành chương trình cuối cùng để máy có thể thực thi.
4.2 Trình thông dịch:
Khác với trình biên dịch, trình thôn dịch không dịch cùng lúc toàn bộ mã chương trình mà nó dịch từng dòng mã lệnh thành những chỉ thị mà máy có thể thực thi ngay. Từng lệnh sẽ được dịch và được thi hành ngay trong khi dịch chứ ko phải dịch xong tất cả, ráp nối lại rồi mới chạy như trình biên dịch. Nhưng đây cũng có thể là điểm bất lợi của trình thông dịch vì cùng 1 câu lệnh như nhau bạn có thể phải dịch lại nhiều lần ở nhiều thời điểm khác nhau. Trong khi ở trình biên dịch bạn sẽ chỉ phải dịch 1lần, khi cần thì trỏ vào đoạn mã chương trình đã được dịch trước đó.
(Sưu tầm)
Cái này biết lâu rồi mà quên, hôm nay ghi vào blog cho nó nhớ (hihi)
gAjax RSS Pausing scroller là code được viết bằng JavaScript nó giúp bạn làm các dòng tin rss chạy trong website của bạn một cách chuyên nghiệp như ta vẫn thường thấy trên các website. Hôm nay tình cờ lang thang và tìm được, share cho anh em nào đang học lập trình web thì vọc chơi cho biết. Link bên dưới có code và hướng dẫn chi tiế, ngoài ra còn nhiều code nữa cho anh em khám phá.
http://www.dynamicdrive.com/dynamicindex18/gajaxpausescroller.htm
Có bao nhiêu loại Ajax Framework?
Đa số Ajax Framework được viết bằng Javascript nên do đó chúng ta có thể gọi là Javascript Framework và sẽ chia ra thành 2 nhóm mỗi nhóm gồm 2 loại là:
Phía Client
. Framework thuộc mức cơ sở hạ tầng tức là ở mức thấp nhất: cung cấp những cách tương tác với các trình duyệt ở mức độ cơ bản, phần nội dung tùy thuộc vào người phát triển. Nhìn chung gồm các tính năng sau:
- Bao gồm đối tượng XMLHttpRequest được bao đóng để tương tác giữa trình duyệt và server.
- Thao tác với XML.
- Thực thi theo DOM được trả về từ XMLHttpRequest.
. Framework thuộc mức ứng dụng: được cung cấp nhiều tính năng hơn, người sử dụng dễ dàng vận dụng và thao tác mà không cần phải quan tâm tới những xử lý nền, triển khai giao diện người sử dụng (GUI) gần giống với ứng dụng Desktop.
Phía Server (thường thì theo một trong 2 loại dưới đây)
- Tự khởi tạo HTML/JS: phía server cung cấp đầy đủ tính năng sinh mã Javascript và kết hợp giữa browser-server. Chỉ phần mã để tương tác phía người dùng có thể tùy biến được.
- Triệu gọi từ xa (Remote Invocation): Javascript triệu gọi trực tiếp tới các hàm (function) từ server và Javascript sẽ nhận kết quả trả về. Ta có thể dùng Javascript để yêu cầu thông tin từ server như chi tiêt về phiên truy cập (session) và truy vấn cơ sỡ dữ liệu (query).
Ajax Framework hiện giờ trên mạng khá nhiều và phong phú cho các lập trình viên về web. Nếu bạn có ý định lập trình web với Ajax, bạn cũng nên xem qua các bộ framework dưới đây.
Các bạn có thể tìm hiểu thêm các Framework tại http://www.ajaxpatterns.org/AJAXFrameworks.
AJAX Coldfusion Frameworks: Bộ Framework cho ngôn ngữ lập trình web ConFusion
ajaxCFC http://www.robgonda.com/blog/projects/ajaxcfc/
CFAjax http://www.indiankey.com/cfajax/
JSMX http://www.lalabird.com/
AJAX Flash Framework: Ajax trên flash (swf) triển khai bằng bộ công cụ Adobe Macromedia Flex
The Flex Ajax Bridge (FABridge) http://labs.macromedia.com/wiki/inde…ework:FABridge
AJAX Java Frameworks: Ajax cho ngôn ngữ lập trình Java
Echo2 :http://www.nextapp.com/platform/echo2/echo/
Tacos: http://tacos.sourceforge.net/
Swato: https://swato.dev.java.net/
ThinkCAP JX: http://www.clearnova.com/
WebORB: http://www.themidnightcoders.com/weborb/aboutWeborb.htm
ZK: http://zk1.sourceforge.net/
AJAX .NET Frameworks: Ajax cho ngôn ngữ lập trình trên .NET (J#.NET, C#.NET, VB.NET và ASP.NET)
AJAX Engine :http://www.mathertel.de/AJAXEngine/
Atlas: http://atlas.asp.net/default.aspx?tabid=47 : được đánh giá là framework tích hợp tốt với ASP.NET và Visual Studio, khả năng triển khai nhanh chóng và dễ dàng
Bitkraft: http://www.tiggrbitz.com/
Magic Ajax: http://www.magicajax.net/
MonoRail: http://www.castleproject.org/index.php/MonoRail
zumiPage: http://www.zumipage.com/
AJAX PHP Frameworks
AjaxAC – Open-souce PHP framework for AJAX http://ajax.zervaas.com.au/
AJAX AGENT – helping WEB become the platform http://www.hemmady.com/ajaxagent
Cajax http://sourceforge.net/projects/cajax
CakePHP Rapid Development Framework http://cakephp.org/
Flexible Ajax http://tripdown.de/flxajax/
My-BIC = Easy Ajax http://litfuel.net/mybic/
PAJAJ – Object Oriented AJAX Framework http://pajaj.sourceforge.net/
Pipeline http://livepipe.net/
TinyAjax – php5 Ajax library http://www.metz.se/tinyajax/index.php
symfony http://www.symfony-project.com/
xajax http://www.xajaxproject.org/
XOAD – PHP / AJAX framework http://wiki.xoad.org/index.php?title=Wiki_Home
Zoop – PHP and AJAX Development Framework http://zoopframework.com/
Nguồn : http://www.freecodevn.com/for@um/showthread.php?t=25091
