Nhiều dự án WCF so với Dự án đơn lẻ trong giải pháp

Question

Hiện tại chúng tôi có 12 dự án WCF trong giải pháp của chúng tôi. Mỗi dự án về cơ bản là điểm cuối của riêng nó. Ví dụ, dự án WCF "Đặt hàng" là điểm cuối Order.svc. 12 điểm cuối này được tiếp xúc bởi một dự án WebHost duy nhất. Dự án WebHost có 12 tệp .svc trỏ đến mỗi vùng/không gian tên tương ứng.

Câu hỏi của tôi xoay quanh việc sử dụng MỘT dự án (một assembly ... một dll) so với nhiều dự án (nhiều hội đồng ... nhiều dll). Những lợi thế/bất lợi, nếu có? Kết quả cuối cùng là như nhau ... bạn có một dự án WebHost cho thấy các điểm cuối này trỏ đến một vùng/không gian tên. Ngoại trừ bạn chỉ cần quản lý một .dll vs 12 .dll trong thư mục bin.

Đối với tôi ưu điểm của một dự án: Tính bảo trì - thay vì 12 dự án, mỗi dự án có nhiều tham chiếu đến giao diện, datacontracts, tiện ích, v.v ... của chúng tôi. Sau đó chúng tôi có thể triển khai một dll và sử dụng cân bằng tải để phân phối đồng đều. Ngay cả khi chúng tôi lưu trữ 3 dịch vụ trên mỗi máy chủ một cách rõ ràng (vì vậy, 4 máy chủ), nếu máy chủ giảm cân bằng tải thì có thể điều chỉnh và 3 máy chủ khác sẽ có những thứ họ cần và tự động chăm sóc mọi thứ. (Tôi đoán như vậy là đúng với 12 .dll của ... chỉ cần có để đảm bảo tất cả 12 .dll là trên mỗi máy chủ).

Thời gian xây dựng - ít dự án hơn = thời gian xây dựng nhanh hơn. Visual studio không phải thực hiện nhiều liên kết và sao chép tất cả các .dll. Thời gian xây dựng nhanh hơn = nhà phát triển hiệu quả hơn và xây dựng và triển khai nhanh hơn.

Tôi hiện đang có một vài đồng nghiệp quan tâm đến "liên kết chặt chẽ" tất cả các dịch vụ WCF của chúng tôi vào một dự án. Đối với tôi, họ là tất cả các dịch vụ WCF tại sao không đặt chúng trong cùng một dự án? Các điểm cuối (tệp .svc) là những gì tách chúng ra. Tôi cũng đã nghe câu hỏi, "còn cái khóa chết thì sao?" Còn nó thì sao? Đó có phải là vấn đề/mối quan tâm hợp lệ không? (Tôi thực sự không biết)

Ngoài ra còn có các câu hỏi được nêu ra nếu .dll bị hỏng. NẾU nó là, sau đó tất cả các dịch vụ đang xuống. Một lần nữa ... đây có phải là một mối quan tâm hợp lệ?

Tất cả các ví dụ tôi đã thấy từ Microsoft và những người khác có các dịch vụ WCF trong một dự án được phân cách bởi các lớp khác nhau. Giao diện là trong dự án của riêng họ ... datacontracts trong dự án khác và như vậy.

Vì vậy, bạn phải làm gì? Làm thế nào để bạn tổ chức nhiều dịch vụ WCF trong Visual Studio Solution của bạn? Học theo tôi.

Answer 1

Chúng tôi đã học được điều này một cách khó khăn. Gần đây chúng tôi đã có một dự án nơi chúng tôi bắt đầu với từng dịch vụ trong dự án riêng của mình và kết thúc việc chuyển đổi thành có tất cả các dịch vụ trong cùng một dự án. Các vấn đề chính khi có mọi thứ trong các dự án khác nhau là:

• Triển khai: Bạn có tạo 12 gói msi cho mỗi dịch vụ, chúng sẽ được triển khai để tách riêng các trang web. Những gì opperations nghĩ về việc chạy 12 kịch bản cài đặt và theo dõi 12 trang web.
• Các dịch vụ gọi nhau, nếu có thì WCF có thể chậm và cấu hình có thể là cơn ác mộng, 12 dịch vụ gọi 11 dịch vụ, với cấu hình cho dev, test và prod.
• Cũng trên các dịch vụ gọi cho nhau, có một lần thực hiện so với cuộc gọi dll trực tiếp
• Dịch vụ có phiên bản chung, ví dụ như thay đổi cơ sở dữ liệu. Nếu có, bạn sẽ cần phải triển khai tất cả các dịch vụ.Quá trình này mất nhiều thời gian hơn một dịch vụ duy nhất, thời gian ngừng hoạt động của bạn sẽ dài hơn

Chúng tôi sử dụng các dự án riêng biệt cho giao diện (Đối tượng) và các đối tượng truyền dữ liệu.

Answer 2

Nói chung nếu các tệp svc của tôi tồn tại trong cùng một cụm, thì chúng đang chia sẻ một số mục đích. Nếu svc chia sẻ đủ mục đích chung để tồn tại trong cùng một hội đồng, thì việc thực hiện cũng chia sẻ đủ mục đích chung để tồn tại trong một hội đồng duy nhất.

Không có bất kỳ vấn đề gì khi có chúng trong các hội đồng riêng biệt, nhưng cũng không có bất kỳ lợi ích nào. Nó là nhiều hơn về xây dựng một giải pháp có cấu trúc rõ ràng, có thể duy trì - và phần lớn là một sở thích cá nhân/tiêu chuẩn/câu hỏi phong cách.

Tách biệt các triển khai nếu bạn thường tách chúng ra - tức là, nếu chúng cho kết quả khác biệt đáng kể hoặc hoạt động như các thành phần riêng biệt trong giải pháp của bạn. Nếu lắp ráp đơn lẻ sẽ khó sử dụng thì tách nó ra.

Tập trung nhiều hơn vào hợp đồng và triển khai. Họ phục vụ các mục đích khác nhau (kỹ thuật) và bạn có thể muốn vạch trần các hợp đồng mà không cần phải triển khai các triển khai.

Có nói tất cả điều đó, tôi muốn có chúng trong một hội đồng duy nhất nhưng ngăn cách bằng cách đặt tên rõ ràng. Ít tập hợp thường dễ quản lý hơn.

Answer 3

Hãy nhớ rằng, bạn không phải triển khai các dự án giống như cách bạn quản lý sự phát triển của chúng. Bạn luôn có thể sử dụng những thứ như ILMerge để biến các dll thành một dll, như một phần của bước xây dựng.

Tôi luôn khuyên bạn nên phát triển một số dịch vụ sử dụng Nhà máy phần mềm (còn gọi là Nhà máy phần mềm dịch vụ web), http://servicefactory.codeplex.com/ giúp thực thi một loạt các phương pháp hay nhất từ ​​nhóm Thực hành MSFT &. Đó là một cách tuyệt vời để tìm hiểu một số thực hành tốt nhất, nhưng một khi bạn tìm hiểu chúng nó thường là tốt hơn/dễ dàng hơn để chỉ thực thi chúng thông qua hướng dẫn tốt/mã đánh giá với nhóm phát triển của bạn. Bằng cách này bạn có thể sử dụng những gì làm việc trong môi trường của bạn, và không sử dụng những gì được cản trở.

Nếu bạn có 12 dịch vụ, bạn quản lý địa ngục cấu hình có thể xảy ra như thế nào? Đặc biệt là khi bạn có các dịch vụ phụ thuộc vào các dịch vụ khác. Cuối cùng đưa tất cả những điều đó, và bất kỳ ràng buộc tùy chỉnh và hành vi, vào cấu hình có thể là một cơn ác mộng triển khai. Ngoài ra, làm thế nào để bạn thực hiện các dịch vụ của bạn được biết đến với những người khác trong doanh nghiệp? Tất cả được thực hiện thông qua truyền miệng, quản lý xây dựng tốt và kiểm soát nguồn?