Giới thiệu: O/R mappers

1/ Dynamic SQL là gì?

Hồi xửa hồi xưa (vâng, mình quen dùng câu này), khi người ta chỉ biết đến cơ sở dữ liệu với FoxPro và Lotus 123, muốn truy cập data thì bạn phải học driver API của một database riêng. Hiển nhiên là rắc rối quá nên SQL (Structured Query Language) ra đời để thống nhất cách giao tiếp và xử lý data trong database.

Ngày nảy ngày nay, .NET 1.1 mưu bá thiên hạ với nhiều hứa hẹn to lớn. Trong đó có ADO.NET. Với Visual Studio 2003, bạn không còn phải học SQL nữa mà chỉ việc kéo-thả 1 table nào đó vào form của bạn là bụp 1 cái, một lô thứ sẽ được tạo ra cho bạn:
- XML schema
- Dataset objects (datarow, table, vv.)
- CRUD queries (Insert, Select, Update, Delete)

A hah, mục cuối cùng mới là điểm hấp dẫn. VS tự động tạo SQL queries phù hợp để cho phép bạn truy cập và xử lý dữ liệu. Thích nhá !!!
Đây chính là dynamic SQL generation. DynaSQL rất phổ biến. Nhiều developers thậm chí còn không để ý họ dùng phương pháp này. Đơn giản 1 điều: chả ai hơi đâu viết SQL cho từng table một cả, do đó bằng cách này hay cách khác họ sẽ viết công cụ để tự tạo query cho nhiều table.

2/ Object Database là gì?
Quay ngược thời gian một tí về... thời tiền sử của cơ sơ dữ liệu. Vâng, tạm quên DynaSQL một tí. Hồi lúc trước khi xuất hiện FoxPro và Quatro, người ta đã đụng đến chuyện làm sao để mô hình hóa một vật gì đó. Thế là họ nghĩ đến Object. Thế làm sao để lưu nó? Họ nghĩ ra ba cách bây giờ bạn thấy rất bình thường: Hierarchial, Relational và Object-oriented.

Mình tạm bỏ qua Hierarchial. Relational chính là database bạn làm quen ngày nay như MS SQL, Access, Oracle, vv. Relational (RDBMS) rất tiện dụng, thế nhưng nó phiền toái ở chỗ một vật thể không đơn giản chỉ là 1 attributes list kiểu như bảng tính trong Excel được. Trong khi đó object-oriented database (ODBMS) lại hoàn toàn cho phép lưu vật thể theo đúng mô hình object của nó. Có điều ODBMS... chậm, tốn kém, không phổ biến bằng RDBMS. ODBMS là xe BMW, còn RDBMS là xe honda 2 bánh.

3/ Relational vs. Object khi lập trình:
Về phương diện lập trình, SQL rất bất tiện, còn ODBMS lại dễ lập trình hơn nhiều. Lấy ví dụ mình có các đối tượng Khách Hàng, Sản Phẩm, và Mua hàng.

với Relational: tạo table KhachHang, SanPham, MuaHang, ChiTietMuaHang. Mỗi table tạo 4 queries cho Insert, Select, Update, Delete. Sau đó, khi khách hàng đặt mua hàng thì cần tạo thêm 2 queries nữa (1 query nếu bạn cố tình biểu diễn khả năng của bạn). Nhưng dầu sao đi nữa, bạn cần phải biết 4 table trên có cấu trúc thế nào, cần biết rõ trường (fields) của từng table để có thể tạo query cần thiết. Khi table bị thay đổi thì bạn cần phải viết lại query.

Thế thì tui sẽ dùng Dynamic SQL thôi. Bạn định nói thế phải không? Vâng, đó là cách hay, nhưng database có chừng 20 table trở lên thì đố bạn nhớ nổi cấu trúc của các table đó. Chưa kể dynamic SQL khi viết code rất khó đọc. Khi gặp lỗi muốn debug SQL query, nhất là dynamic SQL thì... "thích nhá".

với Object-oriented: đơn giản chỉ là khai báo 3 class KhachHang, SanPham, MuaHang. Để mua một sản phẩm, bạn có thể làm như sau:

Code:

Customer cust = database.Get(Customer, Name = "Hải");
MuaHang mh = new MuaHang();

 mh.Customer = cust;
mh.SanPham.Add(someSanPham);
database.Save(mh);

Dễ đọc, dễ hiểu hơn so với dùng SQL. Hơn nữa, bạn có thể nhờ chức năng Intellisense trong Visual Studio để biết ngay 1 object có những property nào, không sợ phải gõ nhầm tên 1 field nào đó như trong SQL.

3/ O/R mapper là gì?
Relational rất phổ biến. Nhưng Object lại dễ lập trình hơn. Thế có cách nào tận dụng cái hay của cả 2 cái được không? Được, đó chính là các công cụ O/R mapper. O/R là những công cụ cho phép lập trình bằng object, cơ sở dữ liệu lại là relational. Mục tiêu của O/R là bạn chỉ cần lập trình bằng object, không cần biết tí gì về SQL hay storedproc.

Quay lại ngày nảy ngày nay, .NET 1.1 lờ tịt đi cái chuyện O/R mà chỉ cung cấp cho bạn cái O/R đơn giản nhất (kéo-thả table vào form đó). Nó chỉ là O/R ... lai căng bởi vì nó không map từ database sang object cho bạn mà chỉ map từ database sang dataset (một dạng in-memory database). Với 1 O/R thực thụ, khi bạn có table Customer trong database thì chỉ cần 1 cái click là có ngay 1 class Customer tương ứng. Tha hồ lập trình với object Customer, còn khi save, load sẽ tự động chuyển về thành relational SQL mà bạn không cần bận tâm gì cả. (Ghi chú: O/R cũng có thể hoạt động theo cách ngược lại: tạo class trước rồi O/R tự tạo table sau)

4/ O/R có phải là phương pháp non trẻ?
Xin thưa với bạn là không. Cũng như Object database, người ta cứ ngỡ nó mới lắm (trong khi ODBMS có từ thời RDBMS mới chào đời), O/R cũng có từ thời người ta biết đến OOP (Object Oriented Programming). Đơn giản là vì dùng SQL cho vài trăm tables sẽ... chết mất

- .NET: Báo với bạn 1 tin vui và 1 tin buồn. Tin vui là bản thân Microsoft đã hỗ trợ O/R cho .NET bằng project ObjectSpaces, dự định ban đầu sẽ có ngay trong ADO.NET 2.0. Tin buồn là... Microsoft đã dẹp tiệm ObjectSpaces rồi. Nhưng đừng buồn quá bạn ạ, Microsoft quyết định merge ObjectSpaces vô WinFS cho Longhorn. Quyết định delay ObjectSpaces đã làm không ít developers tức giận. Tuy nhiên, bạn hãy hy vọng rằng cùng với llllllooooooonnnnnnngggggghorn, ObjectSpaces (dưới danh WinFS) sẽ đem tương lai sáng lạn đến cho database programmer.

- 3rd-party cho .NET: đủ loại thượng vàng hạ cám từ free (vô sourceforge kiếm đi bạn, có nửa tá O/R trong đó) đến thương mại. Nhiều công cụ O/R nên cách sử dụng cũng đủ loại từ dễ đến rắc rối.

- Java: tự search lấy nha bạn, tui ganh tị với mấy tay java vì có nhiều công cụ O/R chín muồi hơn .NET

- Delphi: lúc UML mới chập chững thì Delphi đã có một số project na ná O/R. Nhưng mãi đến Octane (Delphi 8) thì Delphi mới đưa cái ECO (Enterprise Core Object), một dạng O/R, tích hợp luôn vô Delphi IDE. Octane có bán ngoài mấy tiệm dĩa đấy, trên website của Borland cũng có video hướng dẫn từng bước sử dụng ECO cũng dễ hiểu.

5/ Một số link tham khảo

- Google để đọc thêm: O/R mapping
http://www.google.com.vn/search?biw=... Search&meta=

- Giới thiệu về ObjectSpaces:
http://www.microsoft.com/belux/nl/ms...ectspaces.mspx

- ORM.NET: free, class đồ sộ, chậm.
http://www.olero.com/OrmWeb/
(Kiếm thêm trong SourceForge.net để có các free O/R khác)

- Wilson O/R: rẻ tiền.
http://www.ormapper.net/

- LLBL Gen Pro, DataObjects.NET, Gnome: bự, đắt, khó
http://www.llblgen.com/defaultgeneric.aspx
http://www.x-tensive.com/Products/
http://www.genom-e.com/
-------------------------------------------
Tác giả : bienca101

What is a software architecture?

Short version:

Make a complex problem abstract !!!

(if it gets too confusing to understand, refactor it)

'nuff said

Longer version:

Problem: please write a financial application (read: so that my lazy boss can understand how much money he has)

Solution:

1/ Beginner coder:
    Let's start with Access, create 10 tables, throw in 5 forms in VB and we're done.

2/ Intermediate coder:
   Definitely SQL stored procs. Make 20 of 'em, throw in 20 forms, including security login/out (so that no one except me, the master developer can steal money).

  Wait, what do you mean there are bugs? Bugs? Sigh, I'll spend this week sleepless fixing it for you, boss.

3/ Code guru:
  Let's use this spanking new Uber Framework version 9.6 beta 2. I'll spend the next week to read about it and you will have your application 1 hour later.

  Bugs? You humiliate me, sir! There's absolutely no bugs. All those cumbersome features are the framework's fault. You should upgrade to beta 3.

4/ Junior architect:
  Any application starts with 3 layers, see? You need to buy data layer from Microsoft, stick to their recommended best practices & design patterns. For business layer, let's do it from scratch. For presentation layer, let's buy the coolest control suites available.

  No bugs envisioned. My design is perfect. The bugs introduced are developers' faults.

5/ Senior architect:
  All applications need AT LEAST the following:
  - fast, multi-destination logging & instrumentation (log file is not enough)
  - exception publishing (throw new Exception("blah blah") is unacceptable )
  - data abstraction layer (sorry, no SQL, noobs)
  - data binding layer (hands-free, code-free automatic data binding)
  - platform independent, threadsafe, lightweight UI controls (winform, webform are the same, right? )
  - flexible, performant, fault-tolerant, management-free security system
  - workflow engine
  - process engine
  - rule engine
  - query engine
  - report engine (forget those pathetic, pre-built SQL report tools, we're talking about business object reporting tools with slice-n-dice data mining here)

For any of those little, cute items up there, make it:
 - extendable
 - re-usable
 - scalable

Basically, that means there is no design, no commercial product, nothing whatsoever sastisfies my requirements. Thus I have to build it from scratch (let the boss cries, he knows nothing. If he forces me to use a pre-made solution, I'll spend 9 months out of a 10 month project for my own researching, and I will make everything related to the project in the last month)

Bugs? What do you mean somecode somewhere in my some layer is broken? They must be pre-designed features that I forgot to write documents (if I ever do write one)

bienca101

Giới thiệu về WebParts và Content Placeholder (ASP.NET 2.0)

Bài này không chỉ nhiều về những webcontrol đó, nhưng nó giúp ta hiểu khái niệm 2 control đó để làm gì và sử dụng khi nào:

1/ Content Placeholder:

Khi lập trình website, có rất nhiều thành phần có thể tái sử dụng lại nhưng lại khó làm hơn winform nhiều. Lấy ví dụ như menu, navigation, header, bottom, vv... Mấy em làm winform thì nói : "xì, dễ òm, dùng custom controls rồi muốn thả đâu thì thả". Còn dân web thì hoặc là không muốn đụng tới custom control, hoặc là programming language của họ ko hỗ trợ custom controls. Nhưng dân art designer thì lại quá quen thuộc với với chuyện này. Do đó tụi designer đẻ ra khái niệm PlaceHolder image. (Để cái image trống không sẵn ở đó, sau này sẽ gắn cách hình thực sự vào. Để đó trước đặng lúc design layout cho dễ nhìn).

Để dung hòa cả 2 phe, Microsoft xài luôn từ Content PlaceHolder. Có nghĩa là chỉ cần design layout trong một trang .master, còn những phần nào có nội dung thay đổi từ trang này qua trang khác thì cho vào trong cái Content Placeholder.

Về mặt architect, Content PlaceHolder thực chất là 1 blank server control, ko có gì đặc biệt. Tuy nhiên có 1 điểm cực kỳ thú vị là Microsoft đã phát triển từ ý tưởng đơn giản này thành 1 ý tưởng cực hay trong Atlas. Đó là chỉ cần quăng vào trong cái Content Template thì sẽ biến mọi thứ bên trong thành Ajax. Phải công nhận là đây là 1 ý tưởng tuyệt vời, dùng 1 khái niệm đơn giảm để đẻ ra 1 khái niệm tưởng chừng không tưởng.

2/ Web Parts:

Cái này mang nặng tính marketing scheme của Microsoft. Trong lập trình thì ta đã có khái niệm components từ thời nảo thời nào rồi. Ý tưởng là xây dựng những phần riêng rẽ, độc lập để có thể tái sử dụng trong nhiều project khác nhau.

Lấy ví dụ như Security, đa số các web site cần quản lý user, nhưng mỗi khi viết 1 website mới lại phải viết lại từ đầu rất phiền. Do đó Microsoft viết hộ bạn phần security. Bạn chỉ viết kéo thả vào trong website của bạn là xong.

Webpart cũng thế. Webparts là 1 framework hy vọng giúp cho bạn develope những component có thể tái sử dụng lại một cách dễ dàng. Một trong những ứng dụng của web parts mà Microsoft làm giùm bạn là viết những phần cơ bản của 1 portal site.

Tuy nhiên, phải "nói xấu" Micsofot 1 tí xíu là cái tên web-parts rất phù hợp. Những phần Microsoft làm giùm chỉ là những "part" rời rạc, và... hơi bị phiền. Nhưng chê thì phải có khen, design reusable components hòan tòan ko dễ chút xíu nào cả. Bản thân mình nếu cần những tính năng như webpart hỗ trợ sẽ ngay lập tức nhào vào viết mới từ đầu cho phẻ, nhưng nếu design "parts" có khả năng flexible và scalable thì mình chắc chẳng xịn hơn Microsoft được.

(bienca101)