Đối số sử dụng WCF/OData làm lớp truy cập thay vì EF/L2S/nHibernate trực tiếp

Question

Chúng tôi phát triển phần lớn lưu lượng truy cập thấp nhưng các ứng dụng web chuyên biệt cao. Thông thường chúng tôi sử dụng L2S, EF hoặc nHibernate làm lớp truy cập và sau đó ném Asp.Net MVC vào nó và trong đó cho các hoạt động crud bình thường, chúng tôi truy vấn trực tiếp ISession/DataContext nhưng đối với các chức năng/tác dụng phụ nâng cao, lớp dịch vụ.

Bây giờ, tôi đã suy nghĩ về việc xuất bản dữ liệu thông qua OData (WCF Data Service) và truy vấn từ bộ điều khiển (hoặc thậm chí từ jQuery khi công cụ mẫu tốt xuất hiện) và xuất bản các hoạt động dịch vụ thông qua dịch vụ WCF (hoặc như các phương thức tùy chỉnh trên Dịch vụ Dữ liệu WCF?). Ưu điểm/nhược điểm mà kiến ​​trúc này đặt ra là gì?

Tôi có đạt được điều gì đó ngoại trừ độ phức tạp và độ trễ cao hơn không? Phân tách mối quan tâm tốt hơn (hoặc nó chỉ là ảo tưởng)?

Chỉnh sửa: Có thể là một ý tưởng hay khi tạo giải pháp điều khiển ajax hoàn chỉnh với ví dụ. WCF RIA Services? Hoặc làm một mất quá nhiều linh hoạt? Cảm thấy như bạn hoàn toàn có thể gửi quan điểm của bạn từ logic của bạn sau đó, heck, người ta có thể chỉ cần viết HTML tinh khiết, thậm chí không cần một MVC asp.net? nhưng tôi đoán có rất nhiều vấn đề mới phát sinh?

Answer 1

Vì TomTom đề cập đến, bạn không muốn trả chi phí vòng lặp cho OData khi trong quá trình. Nếu bạn có đường thẳng trực tiếp vào cơ sở dữ liệu của mình và đó là cơ sở dữ liệu của ứng dụng của riêng bạn, thì không có lý do gì để đặt WCF Data Services ở giữa. Tôi sẽ tiếp tục sử dụng một trong các tùy chọn khác mà bạn đã đề cập (L2S, EF, nHibernate).

Bây giờ, nếu bạn cần hiển thị dữ liệu trên điểm cuối http của bạn để ứng dụng khác tiêu thụ hoặc thậm chí cho ứng dụng của riêng bạn nếu bạn có một số mã jQuery trong ứng dụng cần truy cập dữ liệu từ máy chủ, thì chắc chắn là OData điểm cuối có thể giúp và WCF Data Services là cách đơn giản nhất để tạo một.

Answer 2

Đừng làm điều đó. Xin lỗi, nhưng đây là một cách tiếp cận quá ngu ngốc. Bạn đang IN MỘT QUY TRÌNH và bạn nhấn mạnh vào việc chạy một kết nối mạng và mã hóa tất cả các dữ liệu đi qua vào XML và trở lại, cộng với chạy nó qua một kết nối HTTP với ngữ nghĩa truy vấn hạn chế? Đừng nói với bất cứ ai bạn thậm chí đã thử.

Tách mối quan tâm là một ảo tưởng ở đây - bạn thay thế mô hình miền được tối ưu hóa cao bằng một lớp dữ liệu được đơn giản hóa.

R SANG NÓI: Tôi yêu OData - tuyệt vời. Nhưng nó không phải là một công nghệ chương trình, nó là một công nghệ FRONT END, giống như ASP.NET MVC - không chỉ cho người dùng cuối, mà còn cho một chương trình KHÁC để tích hợp vào dữ liệu của bạn. Nó nên được sử dụng trong các kịch bản tương tự và khi hiển thị dữ liệu trên đường viền tin cậy (Silverlight - ví dụ - là đường viền tin cậy vì các yêu cầu có thể được giả mạo).

KHÔNG được tối ưu hóa để thay thế trong các lớp thời gian chạy ứng dụng cao cấp như NHibernate.

Answer 3

Để công bằng, có những lợi ích cho phương pháp này có thể lớn hơn các mối quan tâm về hiệu suất, được thừa nhận là rất lớn. Một ứng dụng được xây dựng theo cách này sẽ có các đơn đặt hàng có độ trễ lớn hơn và có thể tốn nhiều thời gian hơn trong các tài nguyên tính toán để thực thi hơn là một giải pháp trong quá trình.

Điều đó đã được nói, trong các tình huống phát triển mà nguồn nhân lực bị hạn chế, điều này có thể hoạt động tốt hơn. Nó cho phép các nhà thầu được nhanh chóng thuê để viết màn hình mới hoặc toàn bộ ứng dụng mới rất nhanh chóng bằng bất kỳ ngôn ngữ nào phù hợp với họ. Các nhà phát triển có thể tăng tốc độ nhanh hơn so với giải pháp sở hữu độc quyền.Không có nhiều mật khẩu trong tệp cấu hình, tiêm một lớp bảo mật tùy chỉnh nếu được yêu cầu, ghi nhật ký hợp nhất và kiểm tra, kết hợp một số cửa hàng dữ liệu vào một tài nguyên nhất quán. Nếu bạn có một nền tảng không đồng nhất, bạn không cần phải viết SDK, chúng đã được viết bằng nhiều ngôn ngữ quan trọng. oData hoạt động rất tốt với MS Excel, đây là một chiến thắng lớn tại nhiều tổ chức. Tùy thuộc vào cấu trúc liên kết mạng của bạn, có thể rẻ hơn và thậm chí nhanh hơn để định tuyến qua internet hơn là sử dụng đường thuê nếu bạn đang ở văn phòng ở xa hoặc phía sau tường lửa (ví dụ: trang web của khách hàng làm demo) .

Đối với các tập dữ liệu lớn, chi phí của yêu cầu và bao bì trở nên kém quan trọng. Ví dụ, đối với các tình huống báo cáo. Trong khi tôi chưa bao giờ thiết kế một cái gì đó như thế này, tôi có thể nhìn thấy nơi nó có thể hữu ích, tùy thuộc vào văn hóa doanh nghiệp của bạn và các nguồn lực sẵn có, để tiêu thụ các điểm cuối oData nội bộ.

Answer 4

Dịch vụ dữ liệu WCF và hỗ trợ OData JSON, vì vậy bạn có thể giảm thiểu tải trọng bằng cách tận dụng điều đó. Ngoài ra, với WCF Data Services, bạn hoàn toàn có thể kiểm soát truy cập dữ liệu của mình. Bạn không cần phải cuộn Entity Framework. Bạn có thể tùy chỉnh mọi thứ. Lợi ích là cấu trúc giao thức được xử lý hoàn toàn cho bạn bằng cách sử dụng các dịch vụ dữ liệu WCF và OData. Và tiêu thụ dịch vụ từ MVC là một tham chiếu thêm dịch vụ. WCF Data Services chạy trên WCF, do đó bạn có khả năng thực hiện các dịch vụ web khác ngoài việc phân phối kiểu OData, vì vậy nó cực kỳ linh hoạt. Có những hạn chế ở đây và ở đó đi kèm với bản chất của OData cũng như cách WCF Data Services xử lý OData, nhưng chúng khá cụ thể và nếu chúng nảy sinh trong kiến ​​trúc của bạn thì có nhiều cách xung quanh chúng.

Nếu giải pháp của bạn được phân tách thành một ứng dụng web duy nhất, khi đó lớp dữ liệu được nhúng trong ứng dụng đó hoạt động tốt. Nhưng nếu bạn có bất kỳ nhu cầu nào để có một ứng dụng hoặc quy trình khác nhấn vào lớp dữ liệu hoặc logic nghiệp vụ được chia sẻ thì hãy khám phá tùy chọn đưa lớp dữ liệu của bạn vào một Dịch vụ Dữ liệu WCF cũng rất đáng giá. Ví dụ, bạn có thể viết một kịch bản PowerShell để gọi một phương thức dịch vụ web trong 2 dòng mã. Vì vậy, nếu bạn có logic miền mà bạn muốn để có thể chạy từ ứng dụng web của bạn và từ một dòng lệnh hoặc nhiệm vụ theo lịch trình sau đó lớp WCF dữ liệu dịch vụ của bạn có thể xử lý kịch bản đó cho tất cả mà không cần phải lặp lại logic hoặc mã.

Nhiều cách để làm da mèo. Tôi đã sử dụng cả hai phương pháp tiếp cận trong các ứng dụng kinh doanh và sẽ không nói rằng một hoặc khác nên tránh. Cả hai đều làm việc tốt và cung cấp nhiều giá trị mà không bị bất lợi.

Answer 5

TomTom có ​​rất nhiều phiếu bầu và mặc dù anh ấy không sai, anh ấy cũng không đúng, mặc dù giọng thuyết phục của anh ấy. Trong trường hợp đặc biệt này, OP dường như đang viết một ứng dụng kiểu nội bộ LOB có lẽ chỉ bị cản trở bởi một dịch vụ OData bắt chước cơ sở dữ liệu bên dưới, nhưng nếu anh ta không bắt chước cơ sở dữ liệu cơ bản thì sao?

Nếu anh ta xây dựng một ứng dụng dựa trên các nguồn dữ liệu khác nhau trong tương lai hoặc không rõ, thì lớp dịch vụ có thể thống nhất, tái hiện, đơn giản hóa và tổng hợp các dịch vụ đó, ngay cả khi một tỷ lệ lớn các truy vấn cuối cùng quay trở lại SQL Server phòng tiếp theo. Tương tự, nếu bạn đang xây dựng một ứng dụng quy mô lớn và theo quy mô, có nghĩa là hàng triệu người dùng chờ đợi vài giây giữa các hành động, không phải hàng triệu giao dịch FX một giờ, sau đó đặt một lớp dịch vụ giữa ứng dụng của bạn dữ liệu là một mẫu chung. Khả năng mở rộng của internet dựa trên nhiều máy chủ HTTP không trạng thái nhỏ và cơ sở hạ tầng bộ nhớ đệm ở giữa.

Trong cuộc sống thực, các truy vấn tương tự sẽ chạy vô số lần, mọi người làm mới trang hoặc nhấp vào cùng một liên kết nhiều lần. Không ai thực sự yêu cầu hàng 10m, bởi vì không nhiều người có thể nhìn vào nó trong một lần.Vì vậy, làm việc trong các trang nhỏ giữ cho dữ liệu chảy và yêu cầu xen kẽ. Bạn cũng có cơ hội để giới thiệu một chia sẻ trong bộ đệm RAM trong lớp dịch vụ, hoặc thậm chí một cơ sở dữ liệu RAM.

Bạn thậm chí có thể thấy rằng bạn cần phải phân phát cơ sở dữ liệu hoặc phân vùng giữa SQL và kho khóa/giá trị. Sau đó, bạn có thể thực hiện các phép nối trong tầng giữa, thu nhỏ và loại bỏ các thứ liên quan và tính toán chuyên sâu ra khỏi máy chủ cơ sở dữ liệu.

Quy tắc với quy mô internet là cơ sở dữ liệu là điểm nóng của bạn và bạn cần phải làm mọi thứ có thể để ngăn chặn bất kỳ ai nói chuyện với nó! Hãy là bộ nhớ cache HTTP cục bộ trong iPad, trong proxy ISP của bạn, trong bộ nhớ cache đầu ra IIS, hoặc trong bộ nhớ cache Redis, tất cả các lớp đó đều giúp truyền tải, giảm gánh nặng.

Vì vậy, nếu Carl đến phỏng vấn với tôi và nói với tôi rằng anh ta đã cân nhắc đặt một lớp OData trước các hộp SQL của mình, tôi muốn được nghe ý kiến ​​của anh ấy.