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:
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
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);
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
No comments:
Post a Comment