Thực hành tốt nhất cho dịch vụ WCF lớn?

Question

Thực tiễn tốt nhất để viết một dịch vụ wcf khá lớn, có chứa rất nhiều OperationContracts và DataContracts?

Làm cách nào để tách các khu chức năng thành nhiều hợp đồng, cách tốt nhất là tạo điểm cuối cho từng khu vực chức năng?

Có cách nào để giữ nguồn cho các phần khác nhau, nhưng vẫn chỉ sử dụng một dịch vụ cho tất cả chúng?

Tôi lấy thông tin tốt ở đâu để lên kế hoạch cho hợp đồng, bao gồm những gì, cách chia nhỏ ...?

Answer 1

Đó là một câu hỏi lớn xung quanh các dịch vụ kể từ khi ra đời. SOA được thực hiện thành công là SOA đã lên kế hoạch đến mức bạn đang nói đến. Có nói rằng, tôi đã luôn luôn nghiêng về hướng dịch vụ tách ra, nhưng sử dụng chúng một cách tổng hợp. Đó là, một số thiết bị đầu cuối khi bạn có một số hợp đồng, nhưng hầu hết trong số chúng chỉ được tiêu thụ bởi một vài thiết bị đầu cuối được tiêu thụ bởi người gọi không có dịch vụ. (wow, đó là một ngụm, thậm chí nó có ý nghĩa không?)

Ngoài ra, tôi khuyên bạn nên có ít hợp đồng nhất có thể. Quá nhiều hợp đồng có thể dẫn đến quản lý kém. Thiết kế hợp đồng tốt sẽ giúp hạn chế số lượng thiết bị đầu cuối và các cuộc gọi dịch vụ. Loại bỏ các khái niệm OO khỏi thiết kế hợp đồng là một cách để làm như vậy. Hợp đồng thiết kế là một chủ đề lớn trong chính nó, nhưng đủ để nói rằng thông qua kế hoạch hợp đồng tốt (lên phía trước), đến thiết kế dịch vụ tốt.

Maarten Mullender writes a great blog trên thiết kế WCF và phải đọc. Ngoài ra còn có một số sách SOA/WCF tuyệt vời đang nổi lên.

Một số sách tốt:

• Pro WCF: Practical Microsoft SOA Implementation
• Programming WCF

Answer 2

này đã giúp ích cho tôi nó xuất phát từ trang web idesign.net và nó đã là tác giả của Juval Lowy:

WCF Coding Standard

Answer 3

Tôi sẽ đi theo dõi ở đây và nói rằng tôi đã sử dụng hợp đồng WCF nguyên khối, các hợp đồng được tách biệt về chức năng (với tối đa mười phương pháp theo hướng dẫn của Juval trong cuốn sách của anh ấy), và tôi cũng đã thử một kiến ​​trúc xử lý thông điệp nơi dịch vụ có một phương thức duy nhất lấy một thông báo cơ sở và các trình xử lý biết 'làm thế nào' cách gỡ bỏ và xử lý thông điệp sau khi nó đi qua dây.

Tôi là một fan hâm mộ lớn của sau này nếu bạn đã có .NET trên cả hai mặt của hàng rào. Oren có một screencast trên ý tưởng với mã. Tôi không biết nhu cầu của bạn là gì nhưng điều này đang làm việc cho tôi.

http://ayende.com/Blog/archive/2008/03/30/Hibernating-Rhinos-8--Going-Distributed-amp-Building-our-own.aspx

Điều đó nói rằng nếu bạn đã đến từ "Tôi cần một dịch vụ WCF lớn", sau đó đi đến một phương pháp có lẽ sẽ không cắt nó cho bạn. Nếu đó là sự thật thì dịch vụ WCF lập trình của Juval Lowy là tiêu chuẩn bạn nên duy trì trong thiết kế của mình.

Answer 4

Tôi có một bài ở đây về cách hoạt động cá nhân nên khác với các hoạt động đang truyền thống:

http://www.iserviceoriented.com/blog/post/Introduction+to+Service+Oriented+Architecture.aspx

Bạn nên kết thúc chỉ với các hoạt động cho các sự kiện kinh doanh thực tế. Nếu bạn ngừng và nghĩ rằng "Tôi cần bật hỗ trợ giao dịch trên dịch vụ web của mình" có nghĩa là bạn chưa thiết kế hoạt động với phạm vi đủ rộng. Bạn không bao giờ phải bật hỗ trợ giao dịch dịch vụ web.

Tôi đánh giá cao blog của Bill Poole cho các khái niệm SOA cấp cao hơn. Dưới đây là một bài đăng để bắt đầu:

http://feeds.feedburner.com/~r/BillPoolesCreativeAbrasion/~3/328955489/service-contract-stability.html

Answer 5

Tôi biết đây là một bài cũ nhưng tôi đang nghĩ đến việc dịch vụ trong cùng một cách như tôi nghĩ về các đối tượng trong lập trình.

Giữ chúng ở mức tối thiểu cho những gì chúng phải làm. Tất nhiên là không đi đến cùng cực, nhưng tôi đang đưa ra quyết định dựa trên các thực thể dữ liệu.

Một dịch vụ cho tài khoản, người ta cho sản phẩm, vv

Không chắc gì ai sẽ nghĩ về điều đó mặc dù ...