Thứ Hai, 4 tháng 3, 2013

sự khác nhau về mô hình 3 tiers và 3 layer


Hỏi đáp về mô hình 3 tầng

1. Mô hình 3 tầng (3-tiers) là gì?
Theo wikipedia thì:
“3-tiers là một kiến trúc kiểu client/server mà trong đó giao diện người dùng (UI-user interface), các quy tắc xử lý(BR-business rule hay BL-business logic), và việc lưu trữ dữ liệu được phát triển như những module độc lập, và hầu hết là được duy trì trên các nền tảng độc lập, và mô hình 3 tầng (3-tiers) được coi là một kiến trúc phần mềm và là một mẫu thiết kế.” (dịch lại từ wikipedia tiếng Anh).
Như vậy, ta có thể mô hình này phân tách ứng dụng ra làm 3 module riêng biệt, bao gồm:
- Tầng Presentation: được dùng để giao tiếp với người dùng, nhiệm vụ chính là hiển thị dữ liệu và nhận dữ liệu từ người dùng.
- Tầng Business Logic: nhiệm vụ chính là cung cấp các chức năng của phần mềm.
- Tầng Data: lưu trữ dữ liệu, cho phép lớp Business Logic có thể tìm kiếm, trích xuất, cập nhật… dữ liệu.
2. Tại sao là 3-tiers mà không phải là 3-layers?
Khi dùng từ layer, chúng ta nói tới việc phân chia ứng dụng thành các thành phần một cách logic theo chức năng hoặc theo vai trò, điều này giúp phần mềm của bạn có cấu trúc sáng sủa, dễ dùng lại, từ đó giúp việc phát triển và bảo trì dễ dàng hơn. Các layer khác nhau khi được thực thi vẫn có thể nằm trong cùng một vùng bộ nhớ của một process, và hiển nhiên việc giao tiếp giữa 2 layer có thể không phải là giao tiếp giữa 2 process, đồng nghĩa với việc chúng không liên quan tới mô hình client/server.
Trái lại, tier liên quan đến cách phân chia một cách vật lý các thành phần trên các máy tính khác nhau.
Điều làm nhiều người nhầm lẫn giữa layer và tier là chúng có cùng cách phân chia (presentation, business, data), tuy nhiên trên thực tế chúng khác nhau. Vì cách phân chia như trên nên 1 tier có thể chứa nhiều hơn 1 layer.
3. 3-tiers có những ưu và nhược điểm gì?
3-tiers là một kiến trúc phần mềm, có nghĩa là bạn có thể dùng nó để xây dựng nên bộ khung tổng thể của ứng dụng. Tuy nhiên bạn cần chú ý những ưu và nhược điểm sau đây để áp dụng nó một cách đúng đắn.
Ưu điểm:
- Dễ dàng mở rộng, thay đổi quy mô của hệ thống: Khi cần tải lớn, người quản trị có thể dễ dàng thêm các máy chủ vào nhóm, hoặc lấy bớt ra trong trường hợp ngược lại.
Nhược điểm:
- Việc truyền dữ liệu giữa các tầng sẽ chậm hơn vì phải truyền giữa các tiến trình khác nhau (IPC), dữ liệu cần phải được đóng gói -> truyền đi -> mở gói trước khi có thể dùng được.
- Việc phát triển ứng dụng phức tạp hơn.
4. Những công nghệ nào hỗ trợ xây dựng các ứng dụng 3-tiers?
Tùy thuộc vào nền tảng, bạn có thể chọn một trong các công nghệ như EJB (J2EE), COM+ (Windows), hay cũng có thể dùng các máy chủ web như nền tảng xây dựng lớp giữa (dùng webservice). Tuy nhiên, EJB và COM+ là hai tùy chọn tốt nhất vì nó có nhiều công nghệ hỗ trợ như Object Pooling, Authentication và Authority, Resource management, Remote Object Access, Transaction…
Các công nghệ truyền thông điệp như JMS hay MSMQ cũng hỗ trợ nhiều trong việc tạo các lời gọi không đồng bộ.
5. Các ứng dụng máy chủ cơ sở dữ liệu có liên quan gì đến mô hình này không?
Có, nó đóng vai trò tầng Data.
Bản thân khi hoạt động, máy chủ CSDL trở thành 1 phần không thể thiếu trong hệ thống, nó chính là nơi chứa dữ liệu của bạn. Việc dùng một hệ CSDL sẵn có là việc nên làm vì nó giúp chúng ta rất nhiều công sức, nhưng điều đó không có nghĩa là nó không thuộc vào hệ thống của chúng ta, chỉ khác ở chỗ đây là một tầng Data được xây dựng sẵn.
6. Lớp Data Access Layer (DAL) thuộc tầng nào?
Lớp Business Logic.
Trái với nhiều người nghĩ, cứ cái gì có chữ Data thì nó phải thuộc lớp 3, tuy nhiên vì DAL chỉ đóng vai trò truy vấn, chứ bản thân nó không cung cấp dữ liệu, và nó vẫn phải được thực thi bởi các Business Object, vậy nên trong đa số trường hợp nó sẽ nằm trong lớp 2 (một số thiết kế tách nó riêng thành 1 tier).
Nên nhớ rằng việc tách riêng ra một DAL giúp bạn có một thiết kế tốt hơn, nhưng không phải là bắt buộc. Và việc tự tạo một DAL với việc dùng chung một tập các lớp truy xuất dữ liệu được cung cấp bởi một công nghệ/công cụ có sẵn như LINQ to SQL, NHibernate hay Entity Framework không có gì khác nhau về kiến trúc hệ thống.
Có lẽ vì sự tồn tại của DAL mà rất nhiều người hiểu nhầm giữa 3-tiers và 3-layers.
7. Tôi nên kiểm tra dữ liệu nhập bởi người dùng ở lớp nào?
Kiểm tra dữ liệu ở lớp giao diện giúp giảm tải cho lớp giữa, phản hồi cũng nhanh hơn. Tuy nhiên sẽ khó có thể đảm bảo sẽ không có kẽ hở để những dữ liệu không hợp lệ được chuyển đến lớp Business Logic và thậm chí lớp Data, vậy nên thông thường việckiểm tra nên được đặt trong tất cả các lớp tùy thuộc vào từng loại dữ liệu và phép kiểm tra. 
8. Tôi có một ứng dụng, nó không có giao diện người dùng vì nó chỉ nhận dữ liệu từ các ứng dụng khác, tôi có thể viết theo mô hình 3-tiers được không?
Có, từ Presentation ở đây không mang ý nghĩa giao diện tương tác với người dùng, mà nó có nghĩa rộng hơn là phần tương tác với các hệ thống bên ngoài, ví dụ Presentation có thể là phầnkết nối để truy xuất dữ liệu đến một hệ thống khác, hay một cổng để tiếp nhận các lệnh do một hệ thống khác chuyển đến.
9. Tôi nên đọc thêm tài liệu nào để hiểu kỹ hơn về mô hình 3 lớp và cách dùng hiệu quả các công nghệ như EJB và COM+?
Bạn có thể đọc thêm 2 quyển:
Designing Enterprise Applications with the J2EE Platform, Second Edition, dành cho người làm J2EE (http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/).
- Application Architecture Guide 2.0, quyển này của các bác MS (http://www.codeplex.com/AppArchGuide/)
Ngay cả khi chưa viết ứng dụng mới mô hình 3-tiers thì bạn cũng RẤT RẤT RẤT nên đọc 2 quyển trên.
10. 3-tiers có giống MVC không?
Không, trong 3-tiers, quá trình đi theo chiều dọc, bắt đầu từ Presentation, sang BL, rồi tới Data, và từ Data, chạy ngược lại BL rồi quay ra lại Presentation.
Còn trong MVC, dữ liệu được nhận bởi View, View sẽ chuyển cho Controller cập nhật vào Model, rồi sau đó dữ liệu trong Model sẽ được đưa lại cho View mà không thông qua Controller, do vậy luồng xử lý này có hình tam giác.
nguồn: http://namdh.wordpress.com/2009/12/31/3-tiers-faq/

Interface vs Abstract class


- Abstract class: là một class cha cho tất cả các class có cùng bản chất. Bản chất ở đây được hiểu là kiểu, loại, nhiệm vụ của class. Hai class cùng hiện thực một interface có thể hoàn toàn khác nhau về bản chất.
-   Interface: là một chức năng mà bạn có thể thêm và bất kì class nào. Từ chức năng ở đây không đồng nghĩa với phương thức (hoặc hàm). Interface có thể bao gồm nhiều hàm/phương thức và tất cả chúng cùng phục vụ cho một chức năng.

$_REQUEST

$_REQUEST
Trong PHP thì $_REQUEST là biến có chứa cả các giá trị của POST và GET, ngoài ra còn chứa các thông tin của $_COOKIE

Sự khác nhau giữa phưong thức POST và GET

 Giống nhau: Đều gửi dữ liệu tới server để xử lý, sau khi người dùng nhập thông tin vào Form
Khac nhau: pt POST việc gửi dữ liệu bảo mật hơn GET, gửi dữ liệu ngầm và dữ liệu không xuất hiện url , 

Còn GET:  Dữ liệu được gửi tường minh và dữ liệu xuất hiện trên URL, đây là lý do khiến nó không bảo mật so với POST, Nó còn bị giới hạn số ký tự bởi URL của web browsers.

GET thực thi nhanh hơn POST vì nhứng dữ liệu gủi đi luôn được Webbrowser cached lại

Khi dùng phương thức POST thì server luôn thực thi và trả về kết quả cho client, còn phương thức GET ứng với cùng 1 yêu cầu đó webbrowser sẽ xem trong cached có kết quả tương ứng với yêu cầu đó ko và trả về ngay không cần phải thực thi các yêu cầu đó ở phía server

Đối với những dữ liệu luôn được thay đổi thì chúng ta nên sử dụng phương thức POST, còn dữ liệu ít thay đổi chúng ta dùng phương thức GET để truy xuất và xử lý nhanh hơn.

Chủ Nhật, 3 tháng 3, 2013

Tại sao không nên dùng Table trong thiết kế website ?


Sau đây là những lý do thiết kế web nên từ bỏ việc sử dụng table và chuyển sang dùng CSS:

   + Table làm gia tăng kích thước của site dẫn đến việc tiêu tốn băng thông không cần thiết.
   + Tiêu tốn thời gian hiệu chỉnh hơn so với việc dùng CSS nếu website có thay đổi.
   + Những người khiếm thị hoặc những người truy cập website bằng DTDD hay PDA sẽ không được hiển thị đúng.
Cuối cùng, tiêu chuẩn web theo W3C hiện tại là sử dụng CSS và tin tốt lành là tất cả các trình duyệt đều hỗ trợ chuẩn này.

Tại sao CSS tốt hơn?

Thiết kế web thiết kế layout với CSS có một số thuận lợi đối với việc SEO Web, điển hình là việc có thể đặt nội dung trước các mã lệnh khác bằng thẻ DIV ( luôn nhớ rằng việc bố trí những  nội dung quan trọng bao gồm từ khóa lên phần đầu của trang web luôn làm gia tăng sự nổi bật của từ khóa ).
Thiết kế web CSS giúp giảm bớt kích thước của trang web và khách tham quan (visitor) không cần phải tải về những dữ liệu mang tính chất trình bày khi xem mỗi trang vì chúng đã được lưu trong bộ nhớ tạm (cache) của trình duyệt.

Những thuận lợi khi dùng CSS

    + Đồng bộ định dạng và dùng chung cho tất cả các trang.
    + Vẫn có thể dùng CSS ngoài mục đích SEO Web.
    + Website sẽ được tổ chức chặt chẽ và dễ bảo trì.
Tóm lại, việc thiết kế web dùng thẻ DIV nói riêng hay CSS nói chung thay thế cho các table lồng nhau sẽ làm giảm đáng kể kích thước trang, tổ chức website được chặt chẽ hơn, dễ bảo trì hơn và gia tăng tính khả dụng.
Một điểm không thuận lợi khi sử dụng CSS là chúng ta phải học về nó, tuy nhiên, điều này không quá khó cho các webmaster.
Cả hai phương pháp, table lồng nhau và CSS đều được quan tâm khi nói về SEO Web. Nhưng chúng ta đã biết, các robot sẽ quét qua toàn bộ mã trong các trang web mà chúng viếng thăm, tuy nhiên, nếu  số lượng mã quá lớn, các robot có thể không tiếp cận trọn vẹn, từ đó, việc bố trí nội dung sao cho các robot có thể tiếp cận là một điều khá quan trọng và điều này chắc chắn việc dùng CSS sẽ làm tốt hơn.
Bây giờ chúng ta sẽ xem qua vài bước thực tế về việc sử dụng thẻ DIV so với table để nâng cao sức hấp dẫn cho các công cụ tìm kiếm ( SEO Web ).

Tối ưu hóa trang web dựa trên table

Khi một trang web được tạo ra khi dùng table, thông thườngng phần nội dung chính sẽ nằm ở ô dưới cùng bên phải của table. Các robot quét 1 trang web theo chiều từ trái sang phải và từ trên xuống dưới sẽ đi qua rất nhiều đoạn mã trước khi tiếp cận được nội dung này. Để tránh điều này, chúng ta phải bố trí nội dung vào những ô đầu tiên nằm ở phần trên của table và cách tốt nhất là đưa nội dung lên trên mã HTML bằng cách dịch chuyển phần menu từ trái sang phải (menu thường được bố trí bên trái).
- See more at: http://lmt.com.vn/home/php/tim-hieu-php/item/717-tai-sao-khong-nen-dung-table-trong-thiet-ke-website.html#sthash.iNXwyeL4.dpuf