Thực hành tốt về Giải pháp Visual Studio [đã đóng]

Hy vọng một câu hỏi tương đối đơn giản. Tôi đang bắt đầu làm việc với một dự án nội bộ mới để tạo ra khả năng dễ điều khiển của các thiết bị được sửa chữa trong các tòa nhà.

Cơ sở dữ liệu được lưu trữ từ xa trên máy chủ web và sẽ được truy cập thông qua API web (đầu ra JSON) và được bảo vệ bằng OAuth. GUI giao diện người dùng đang được thực hiện trong WPF và mã doanh nghiệp trong C #.

Từ đây, tôi thấy các lớp khác nhau Trình bày / Ứng dụng / Kho dữ liệu. Sẽ có mã để quản lý tất cả các lệnh gọi được xác thực tới API, lớp để thể hiện các thực thể (đối tượng kinh doanh), các lớp để xây dựng các thực thể (đối tượng kinh doanh), các bộ phận cho GUI WPF, các bộ phận của chế độ xem WPF, v.v.

Là tốt nhất để tạo điều này trong một dự án duy nhất, hoặc chia chúng thành các dự án riêng lẻ?

Trong thâm tâm tôi nói nó nên là nhiều dự án. Tôi đã thực hiện cả hai cách trước đây và thấy việc thử nghiệm trở nên dễ dàng hơn với một giải pháp dự án duy nhất, tuy nhiên với nhiều dự án thì phụ thuộc đệ quy có thể tăng lên. Đặc biệt là khi các lớp có giao diện để kiểm tra dễ dàng hơn, tôi đã thấy mọi thứ có thể trở nên khó xử.

Nó phụ thuộc vào quy mô của dự án

Đây là hướng dẫn tôi có xu hướng sử dụng

• Một dự án nhỏ, với một số ít trang hoặc ít hơn, tôi hầu như luôn giữ một dự án duy nhất.

• Nếu lớp Truy cập dữ liệu của dự án nhỏ lớn hoặc phức tạp, tôi có thể tách nó ra thành lớp riêng của nó, nhưng nếu không thì nó chỉ nằm trong thư mục riêng của nó.

• Nếu dự án lớn hơn, hầu như tôi sẽ luôn có một dự án riêng cho DAL và bất kỳ sự phân tách nào nữa phụ thuộc vào ranh giới giữa chức năng của ứng dụng.

• Nếu ứng dụng có nhiều mục đích, mỗi mục đích có chế độ xem, chế độ xem, v.v., thì tôi thường sẽ tách từng phần vào khu vực riêng của nó. Nếu mỗi phần nhỏ, tôi tách chúng bằng một Thư mục. Nếu mỗi phần lớn, tôi sẽ tách chúng theo một dự án.

• Nếu tôi có nhiều dự án mà cần phải tham khảo cùng một tập hợp các đối tượng ( ViewModelBase, RelayCommand, vv), tôi sẽ tạo một dự án chỉ dành riêng cho các đối tượng cơ sở hạ tầng dùng chung.

• Nếu tôi có số lượng lớn các kiểu / mẫu / tài nguyên tùy chỉnh được chia sẻ, tôi sẽ tạo một dự án chỉ dành cho những người đó.

Một ghi chú bên lề, tôi đã phạm sai lầm với dự án WPF lớn đầu tiên của mình và tách chúng ra bằng cách đưa Mô hình vào một dự án, Lượt xem trong dự án khác và ViewModels trong một phần ba. Tôi có thể nói với bạn bây giờ đó không phải là cách để đi, vì bảo trì trở thành một cơn ác mộng :)

Tôi đã thấy kết quả tốt nhất với một dự án trên mỗi lớp, cộng với dự án thử nghiệm trên mỗi lớp. Tôi đã thấy một vài ứng dụng không thể hoàn thành trong 10 dự án hoặc ít hơn trong giải pháp, trong đó giải pháp bao gồm mọi thứ .

Đừng rơi vào cái bẫy của việc sử dụng các dự án mà bạn thực sự muốn đặt tên. Hàng tấn dự án không thêm gì ngoài chi phí không có lợi.

IMHO tách biệt hầu như luôn luôn tốt hơn. Tôi hầu như luôn tách biệt lớp dữ liệu của mình trừ khi dự án là 100% tầm thường. Lý do là bởi vì lớp dữ liệu có xu hướng được truyền xung quanh thường xuyên nhất. Hiếm khi bạn kết nối GUI với nhiều lớp dữ liệu và mong đợi nó hoạt động tốt. Kịch bản phổ biến hơn nhiều là bạn có một lớp dữ liệu duy nhất và bạn muốn nó được phân phối trên nhiều GUI (ví dụ: ASP.Net, WPF và ứng dụng Silverlight). Thật tuyệt vời khi bạn chỉ có thể xây dựng dự án lớp dữ liệu và đưa dll đó làm tham chiếu trong GUI tiếp theo mà bạn xây dựng.

Đối với tôi, 4 * là con số kỳ diệu. Một dự án cho mỗi lớp và một dự án xác định tất cả các giao diện / DTO cần thiết để giao tiếp giữa chúng.

* 7 nếu bạn đếm bài kiểm tra đơn vị

Tôi đã luôn sử dụng một giải pháp duy nhất nếu tôi đang làm việc trên các lớp khác nhau đó hoặc nếu có sự liên kết chặt chẽ với chúng. Tôi muốn đạt F5 và có tất cả các dự án được xây dựng lại nếu cần. Tôi không nghĩ có một cách "đúng" để làm điều đó.

Hương vị cá nhân của nó, điều quan trọng nhất là phải nhất quán . Cá nhân tôi có một dự án tách riêng cho từng lớp của ứng dụng nên sự tách biệt là rõ ràng.

Sự gia tăng số lượng dự án phải làm với việc cho phép thử nghiệm đơn vị và đơn giản hóa biểu đồ phụ thuộc đến mức mọi thứ không phức tạp đến mức thay đổi trong một phần của ứng dụng phá vỡ mọi thứ trong các phần dường như không liên quan của ứng dụng.

Nó hoạt động khi tôi thực hiện một số loại đảo ngược phụ thuộc, để đặt tất cả các "hợp đồng", giao diện, lớp trừu tượng, đối tượng truyền dữ liệu vào một cụm. Trong một hội nghị khác, tôi đặt bất cứ điều gì nói về cơ sở dữ liệu. Kiểm tra đơn vị có được lắp ráp riêng của họ. Nếu UI về cơ bản là không thể kiểm chứng được (ví dụ như win win của ASP.NET), thì có thể có lợi ích đáng kể khi chia UI thành mã có thể kiểm tra và mã không thể kiểm tra - mỗi cụm. Đôi khi một số mã bắt đầu hiển thị không liên quan gì đến cơ sở dữ liệu, giao diện người dùng hoặc bất cứ điều gì tôi đã đề cập cho đến nay - đó là mã mà tôi mong muốn nằm trong khung .NET. Mã đó tôi sẽ đưa vào một hội đồng tiện ích, hoặc ít nhất là đặt nó vào bất cứ tập hợp gốc nào (có thể là mã có giao diện.

Nếu tất cả các hội đồng tham chiếu tất cả các hội đồng, hoặc gần như vậy, thì chúng nên được hợp nhất trở lại thành một hội đồng duy nhất. Nếu bạn hoặc những người trong nhóm của bạn thiếu kỷ luật để không đặt mã lớp dữ liệu vào UI và UI trong lớp dữ liệu, thì hãy đơn giản hóa mọi thứ bằng cách hợp nhất tất cả lại thành một lớp.

Một số phiên bản của Visual Studio gặp vấn đề về hiệu năng ở khoảng 15 hội đồng, đôi khi nó phụ thuộc vào loại dự án nào. Chiến lược dỡ tập tin dự án đôi khi có thể giúp đỡ mặc dù.

Lý do chính đáng duy nhất để có nhiều hơn một dự án, là nếu bạn cần chia sẻ một tập hợp các lớp và tệp trên nhiều ứng dụng.

Nếu các dự án chỉ được sử dụng bởi một ứng dụng, thì chúng không nên được thực hiện ngay từ đầu. Sử dụng không gian tên thay thế. Hãy tự cứu mình khỏi những rắc rối của tài liệu tham khảo vòng tròn, chi phí dll và sự nhầm lẫn của dự án khi tìm kiếm tệp.

Đọc bài viết này để được giải thích rõ hơn về lý do tại sao lại như vậy: http://lostechies.com/chadmyers/2008/07/16/project-anti-potype-many-projects-in-a-visual-studio- tập tin giải pháp /

Và như bài báo nêu, tôi hoan nghênh bất kỳ ai có lý do hợp lệ để có nhiều dự án ngoài việc chia sẻ mã trên ứng dụng để cho tôi biết đó là gì, vì tôi nghi ngờ không có dự án nào.