Nhiều ứng dụng trong một giải pháp Visual Studio duy nhất [đã đóng]


17

Tôi đang làm việc cho một công ty muốn đặt tất cả các ứng dụng .Net của họ (ứng dụng web, ứng dụng Windows và ứng dụng bảng điều khiển) vào cùng một giải pháp Visual Studio.

Tôi đang tìm kiếm kinh nghiệm từ các nhà phát triển, những người tự cấu trúc các ứng dụng của họ theo cách này hoặc những người làm việc trong một công ty làm việc này. Đây có phải là một ý tưởng tốt?

  • Các pro / con là gì để đưa tất cả các ứng dụng của bạn vào một giải pháp duy nhất thay vì có các giải pháp riêng biệt cho mỗi ứng dụng?

  • Visual Studio nhanh như thế nào với giải pháp gồm hơn 20 dự án?

  • Và làm thế nào ổn định là tập tin giải pháp với sự phát triển đồng thời kiểm soát nguồn?


Hãy nhớ rằng câu trả lời có thể dành riêng cho các phiên bản cụ thể của Visual Studio.
stakx

Câu trả lời:


21

Gần đây, chúng tôi đã chuyển gần như tất cả các mã nguồn trong công ty của tôi sang một giải pháp duy nhất.

Tại sao?

Ban đầu, chúng tôi đã có hàng tá giải pháp. Một số dự án từ một giải pháp sử dụng lại các dự án từ một dự án khác và không ai quan tâm đến việc sử dụng trình quản lý gói. Ngày bạn thay đổi đáng kể một dự án được sử dụng gần như ở mọi nơi, mong đợi hàng giờ và hàng giờ mất việc cho toàn bộ công ty cho những ngày hoặc tuần tiếp theo. Điều tồi tệ nhất là bạn thậm chí không thể biết chính xác điều gì sẽ bị ảnh hưởng bởi sự thay đổi.

Hợp nhất tất cả các mã vào một giải pháp là một giải pháp thay thế. Nó hoạt động tốt trong thời điểm này, và các phụ thuộc bây giờ dễ theo dõi. Bạn muốn sửa đổi một phương thức nhưng cũng theo dõi hậu quả mà thay đổi này có thể có ở bất kỳ đâu trong cơ sở mã? Visual Studio có thể làm điều đó một cách dễ dàng. Đối với tôi, đó là một thành công.

Tích hợp liên tục bây giờ cũng dễ dàng hơn. Một giải pháp để biên dịch và triển khai. Gần như không có gì để cấu hình.

Có khả năng mở rộng?

Hiệu suất-khôn ngoan, tôi đã rất ngạc nhiên bởi Visual Studio . Tôi nghĩ rằng nó sẽ bắt đầu khóc với một giải pháp với, nói, 50 dự án. Ngày nay, có hơn 200 dự án; Visual Studio dường như có thể mở rộng đủ để quản lý chúng như thể chỉ có 20 người trong số họ. Vâng, có những thứ cần có thời gian. Nếu bạn biên dịch lại mọi dự án, với các hợp đồng Mã, phân tích mã được bật theo mặc định, v.v., hãy chờ đợi nó sẽ mất một thời gian. Nhưng không ai có thể mong đợi biên dịch 200 dự án nhanh như 10, và nhân tiện, bạn không nên: đây là vai trò của máy chủ tích hợp liên tục. Thời gian khởi động (khởi động nguội, sau đó tải giải pháp) nhanh chóng ấn tượng ; có thể không nhanh như với 10 dự án, nhưng vẫn rất chấp nhận được (dưới 20 giây trên một máy đã mua hơn năm năm trước).

Để đi xa hơn, các dự án dỡ tải có hệ thống là một ý tưởng tốt (và thực sự dễ dàng khi các dự án được tổ chức trong các thư mục trong giải pháp). Nếu ai đó làm việc trên một cái gì đó chỉ cần ba dự án được tải, thì không cần phải tải tất cả 200 dự án (tất nhiên trừ khi, phụ thuộc có thể bị ảnh hưởng).

Kiểm soát phiên bản cũng hoạt động như mong đợi (Tôi đang sử dụng máy chủ SVN, nếu có vấn đề). Tôi đã không làm việc trong một môi trường đồng thời thực sự, với, hàng chục nhà phát triển thường xuyên cam kết mã, nhưng tôi sẽ tưởng tượng rằng điều này sẽ không có quá nhiều vấn đề. Chỉ cần cẩn thận với các trường hợp nhiều nhà phát triển thêm dự án mới cùng một lúc: hợp nhất tệp .sln không phải là điều dễ nhất để làm.

Phần kết luận

Nếu tôi phải chọn lại quyết định:

  1. Tôi vẫn sẽ di chuyển mọi thứ vào một giải pháp duy nhất. Điều này làm giảm đáng kể nỗi đau của sự phụ thuộc bị phá vỡ, và lợi ích này là hoàn toàn xứng đáng. Có một nơi tập trung cho tất cả các mã cũng là một ý tưởng tốt; điều này làm cho nó có thể, ví dụ, để tìm kiếm thứ gì đó trong Visual Studio. Tôi cũng có thể làm việc trên hai dự án liên quan đến yếu và vẫn chỉ có một cửa sổ Visual Studio được mở.

  2. Tôi cũng sẽ nghiên cứu thêm một chút về NuGet và khả năng lưu trữ một máy chủ NuGet riêng. Quản lý các phụ thuộc thông qua NuGet có thể giải quyết một số vấn đề khi bạn không muốn hợp nhất một vài dự án vào giải pháp chung. Cá nhân tôi không gặp phải trường hợp như vậy, nhưng tôi tưởng tượng rằng các công ty khác có thể có.

  3. Cuối cùng, đầu tư vào một ổ SSD cho mọi nhà phát triển có thể tạo ra sự khác biệt rất lớn. Nhưng bạn không cần, và trong trường hợp của tôi, cơ sở mã vẫn được lưu trữ trên một ổ cứng thông thường.


2
Chỉ cần một số điểm FYI: Bạn cũng có thể mở các dự án thông qua tệp .csproj trong VS nếu tốc độ / hiệu suất là một vấn đề. "Máy chủ riêng" của NuGet chỉ là một thư mục mạng (và thêm thư mục đó làm vị trí nguồn gói trong VS) - chỉ cần thả các tệp nupkg ở đó và nó hoạt động.
Steven Evers

Cảm ơn, MainMa đã chia sẻ kinh nghiệm của bạn với một thiết lập giải pháp duy nhất; một câu trả lời rất chi tiết và hữu ích. Một sự bảo lưu mà tôi có là có tất cả các ứng dụng cùng nhau trong một giải pháp là phải cung cấp cho nhà phát triển cơ sở quyền truy cập vào mọi thứ. Chúng tôi sử dụng Ankhsvn và tôi thà cung cấp cho một nhà phát triển cơ sở URL cho một ứng dụng mà tôi muốn họ làm việc hơn là cho họ quyền truy cập vào mọi thứ. Bất kỳ suy nghĩ về điều này?
BruceHill

@BruceHill: với SVN, bạn có thể định cấu hình chính xác ai có quyền truy cập vào cái gì. Nhà phát triển cơ sở vẫn có thể thấy mọi thư mục gốc (xem câu hỏi của tôi trên Server Fault ), nhưng sẽ không thể truy cập các dự án bị hạn chế.
Arseni Mourzenko

2
Làm việc cho một vài công ty lớn với các nhóm nhà phát triển lớn cam kết mã hàng ngày tôi có thể nói với bạn rằng phương pháp giải pháp duy nhất không hoạt động. Mỗi dự án là chi phí chung. Tải lên, xây dựng và thượng đế biết những bước xây dựng trước / sau mà ai đó có thể đã gắn với các dự án đã nói. Giờ đây với một nhóm lớn các nhà phát triển, bạn sẽ có những thay đổi trên nhiều dự án đó mỗi ngày. Bao gồm các bài kiểm tra đơn vị đang chạy, vv với mỗi lần đăng ký để tích hợp liên tục và sau đó bạn có nhiều chi phí hơn. Có một giải pháp duy nhất cho mỗi đơn vị có thể triển khai (dịch vụ, trang web) và sử dụng trình quản lý gói như NuGet.
Luôn học

8

Đây là mục đích sử dụng.

Các pro / con là gì để đưa tất cả các ứng dụng của bạn vào một giải pháp duy nhất thay vì có các giải pháp riêng biệt cho mỗi ứng dụng?

  • ưu:
    • tài liệu tham khảo dễ dàng hơn giữa các dự án
    • gỡ lỗi / bước qua dễ dàng hơn
    • dễ dàng hơn để đính kèm vào các quy trình (ví dụ: bạn đang bước qua một dịch vụ windows, khi nó nhảy tới mã thư viện dùng chung và nó chỉ hoạt động vì tất cả các biểu tượng đã được tải và chiếm)
    • tìm kiếm mã trong ide hoạt động tốt hơn (bạn không nhất thiết phải biết dự án mà mã bạn đang tìm kiếm nằm ở đâu)
    • người thay đổi dự án chéo dễ quản lý hơn (nghĩa là bạn đã thay đổi mã thư viện, do đó bạn phải cập nhật mã máy khách cùng lúc, với 1 lần đăng nhập)
  • Nhược điểm:
    • tốc độ xây dựng: nếu bạn có thói quen "xây dựng lại tất cả" thì việc xây dựng sẽ mất nhiều thời gian hơn. Lâu hơn nhiều, và các bản dựng gia tăng đôi khi có hành vi sôi nổi.
    • tốc độ ide: xem tiếp

Visual Studio nhanh như thế nào với giải pháp gồm hơn 20 dự án?

Với hơn 20 dự án ... có thể không quá tệ. Tôi đã thấy nhiều hơn mà không có vấn đề với VS. Nó khá ổn định / nhanh chóng. TUY NHIÊN ... nếu đó là một vấn đề, nó có thể được giảm nhẹ: mở .csproj trong VS và làm việc từ đó. Bạn không nhận được lợi ích của việc có mọi thứ trong một giải pháp, nhưng bạn luôn có thể mở lại sln khi bạn cần và làm việc chỉ trong .csproj khi bạn cần (như bạn làm bây giờ).

Và làm thế nào ổn định là tập tin giải pháp với sự phát triển đồng thời kiểm soát nguồn?

Tệp giải pháp chỉ thay đổi khi bạn thêm / xóa dự án hoặc đối tượng mức giải pháp, vì vậy nó hiếm khi thay đổi. Đó là xml, vì vậy bạn có thể thấy những gì trong đó. Họ hiếm khi thay đổi.


Steve, bạn nói "Đây là mục đích sử dụng." Bạn có thể cung cấp một tài liệu tham khảo cho điều này? Cảm ơn!
cải cách
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.