SqlDataSource vs ObjectDataSource

Question

Nếu một trang web cần một số dữ liệu, tại sao không chỉ có một cuộc gọi SQLDataSource một thủ tục được lưu trữ? Tại sao lại sử dụng một ObjectDataSource để gọi một đối tượng nghiệp vụ mà sau đó gọi thủ tục lưu sẵn? Tôi hiểu rằng các ứng dụng khác (cho phép ứng dụng máy tính để bàn) được xây dựng trên khung .net có thể truy cập các đối tượng kinh doanh, nhưng điều gì xảy ra nếu ứng dụng sẽ luôn là ứng dụng web?

Để được rõ ràng hơn:

Khi ta nên sử dụng một SqlDataSource hoặc ObjectDataSource?

Làm thế nào để thúc đẩy sự lựa chọn?

Answer 1

Chỉ có một SQLDataSource là hoàn toàn hợp lệ, nếu nó chỉ là bản demo, mẫu thử nghiệm hoặc bản hack nhanh. Thật nhanh chóng, thật dễ dàng, nó chỉ hoạt động và cung cấp cho bạn kết quả bạn cần.

Tuy nhiên, khi ứng dụng được thiết kế và xây dựng trong thời gian dài và dự đoán rằng mọi thứ (yêu cầu, mong muốn của khách hàng, cuối cùng lược đồ cơ sở dữ liệu) có thể thay đổi, thì có thể có ý nghĩa hơn nhiều để giới thiệu một cách thích hợp " kinh doanh "lớp - mô hình hóa các đối tượng nghiệp vụ của bạn làm đối tượng, và sau đó cung cấp ánh xạ từ cơ sở dữ liệu cơ bản đến các đối tượng nghiệp vụ đó.

Khi nói đi - bạn có thể giải quyết khá nhiều thứ trong khoa học máy tính bằng một lớp nữa (hoặc trừu tượng) - cùng giữ ở đây.

SURE: bạn có thể truy cập thẳng vào cơ sở dữ liệu, và chắc chắn, lúc đầu tiên và cho lần lặp đầu tiên, có thể (hoặc có thể) là cách nhanh nhất. Nhưng về lâu dài, khi một ứng dụng được xây dựng để kéo dài, nó thường là một cách nhanh chóng và bẩn - chi phí bảo trì, chi phí bảo trì, chi phí và công sức cần thiết để thay đổi theo nhu cầu của bạn và của khách hàng sẽ phát triển và khá nhanh chóng, giải pháp nhanh chóng này không còn tuyệt vời nữa, về mặt nỗ lực. Vì vậy, để tổng hợp điểm của tôi: có, ban đầu, sử dụng một nguồn dữ liệu SQL trực tiếp có thể nhanh hơn và dễ dàng hơn - vì vậy hãy sử dụng nó khi đó là điểm quan trọng: để hoàn thành công việc cho một bản demo nhanh, bằng chứng ứng dụng phong cách khái niệm. Nhưng về lâu dài, khi bạn nhìn vào tuổi thọ của một ứng dụng, bạn nên đầu tư nhiều hơn một chút (thiết kế và mã hóa) để thêm lớp trừu tượng này để các trang web của bạn không trực tiếp phụ thuộc vào các chi tiết của cơ sở dữ liệu bên dưới.

Marc

Answer 2

Nếu bạn có một lớp doanh nghiệp mà bạn đang sử dụng trong các dự án của mình, ObjectDataSource là lựa chọn tự nhiên. Điều này phù hợp với nhiều ORM, và nhiều người trong số họ cung cấp thêm lợi ích (xác nhận, hoàn tác, vv). Nó cũng cho phép bạn truy cập bất kỳ thuộc tính nào khác mà bạn có trên các đối tượng kinh doanh của mình - không chỉ các trường SQL trực tiếp. Điều này có thể thực sự hữu ích khi gắn kết - vì nó cho phép bạn chỉ liên kết với các thuộc tính trong đánh dấu thay vì phải viết nhiều mã phía sau.

Nếu bạn đang đi tuyến đường này, trộn SQLDataSource và ObjectDataSource có thể dẫn đến sự nhầm lẫn của nhà phát triển tiếp theo để nhận dự án của bạn. Trong trường hợp này, tôi gắn bó với ObjectDataSource để thống nhất mã.

Nếu bạn không có lớp nghiệp vụ và chỉ cần nhấn SQL trực tiếp - hãy sử dụng SQLDataSource. Sở thích cá nhân của tôi là tất cả các mã SQL của bạn phải ở trong một lớp kinh doanh hoặc dữ liệu, và vì tôi gần như không bao giờ sử dụng SQLDataSource.

Answer 3

nếu bạn có thể applay mã lớp doanh nghiệp của bạn trong thủ tục lưu trữ sự của nó tốt hơn để sử dụng SqlDataSource

Answer 4

Về lý thuyết ObjectDataSource là tốt hơn. Nhưng tất cả phụ thuộc vào cách mô hình đối tượng được viết và ghi lại. Chúng tôi thuê ngoài một công ty đã sử dụng trình tạo mã tùy chỉnh (mà họ sẽ không cung cấp cho chúng tôi) để sản xuất tất cả các lớp. Hóa ra là cơn ác mộng để tạo ra những thay đổi nhỏ, chẳng hạn như thêm thuộc tính hoặc thay đổi kiểu trường. Tôi hiện đang loại bỏ hầu như tất cả mọi thứ họ đã làm và chỉ sử dụng các thủ tục được lưu trữ mà họ đã viết.

Mục tiêu dài hạn của tôi là viết lại ứng dụng từ đầu bằng công cụ tạo mô hình thương mại & trình tạo mã. Nếu bạn định sử dụng objectdatasource, tôi khuyên bạn nên tìm một công cụ mô hình hóa tốt bao gồm trình tạo mã linh hoạt.