Thực hành tốt nhất cho tổ chức dự án với ASP.NET MVC

Question

Gần đây tôi đã tải xuống số tuyệt vời của Rob Conery ASP.NET Storefront reference application và tôi thấy nó cực kỳ có tính hướng dẫn. Một câu hỏi nảy ra trong đầu là nơi mà người ta nên đặt các lớp Mô hình (và các lớp dữ liệu mà chúng phụ thuộc vào). Mẫu dự án MVC tạo ra một thư mục Model. Nhưng dường như với tôi rằng tôi sẽ phục vụ tốt hơn việc phá vỡ mô hình thành một hội đồng dự án riêng biệt để nó có thể được các ứng dụng tiềm năng khác sử dụng lại (ví dụ: các công cụ quản lý liên quan đến miền ứng dụng của trang web)?

Tôi rất tò mò muốn có ý kiến ​​của mọi người.

Answer 1

Nó thực sự phụ thuộc vào quy mô của dự án. Không có giá trị cố hữu trong việc có một mô hình "mô hình" riêng biệt, vì bạn có thể kiểm tra một dự án ứng dụng Web (bao gồm các dự án MVC).

Answer 2

Tôi đồng ý. Trừ khi ứng dụng chỉ là ứng dụng web đơn lẻ, tôi sẽ chia nó ra thành một dự án riêng biệt. Thông thường, tôi sẽ có một giao diện ứng dụng web sử dụng một hoặc nhiều dịch vụ windows để thực hiện các tác vụ lặp lại, tự động (gửi phí, gửi thông báo, v.v.) và một hoặc nhiều công cụ ứng dụng giao diện điều khiển để cung cấp cơ sở người dùng ứng dụng từ thư mục doanh nghiệp của chúng tôi - ứng dụng của tôi thường là các ứng dụng mạng nội bộ chỉ có thể áp dụng cho các tập hợp con của toàn bộ người dùng của chúng tôi. Việc có các mô hình (lớp dữ liệu) trong một dự án riêng biệt cho phép tôi dễ dàng chia sẻ nó với tất cả các ứng dụng khác.

Answer 3

Nếu mô hình của bạn là Đối tượng chuyển miền, sau đó có chúng trong một hội đồng riêng biệt sẽ cho phép bạn sử dụng lại chúng. Nếu ứng dụng của bạn là một ứng dụng MVC đơn giản, và đó là tất cả để có nó, hoặc bạn chỉ làm nó để kiểm tra đơn vị, nó không cần thiết. Nếu không, bạn có thể:

• Bạn có sử dụng lớp dịch vụ web để chuyển đối tượng mô hình đến ứng dụng mvc để sử dụng trong ứng dụng của bạn hay không. Điều này sẽ là cần thiết nếu bạn thực hành không cho phép các ứng dụng web có quyền truy cập trực tiếp vào cơ sở dữ liệu. Trong trường hợp đó, bạn có thể có một mvc gọi một dịch vụ web để xác thực và kéo dữ liệu.

• Bạn dự định xây dựng các ứng dụng khác bằng cách sử dụng cùng một kiểu, như các công cụ quản lý bạn đã đề cập.

Tôi hy vọng điều đó sẽ hữu ích. Trên một mặt lưu ý, bạn có thể muốn đặt các phần "phổ biến" trong khung công tác của riêng mình, bao gồm "mô hình" (thực thể, đối tượng tên miền, bất kỳ tên nào bạn thích).

Answer 4

Các cụm riêng biệt! = Khớp nối lỏng lẻo.

Answer 5

Tôi muốn có các dự án riêng biệt cho mô hình, truy cập dữ liệu và logic nghiệp vụ của mình. Tôi cũng có giao diện ở mỗi lớp. Điều này làm cho các thử nghiệm với mocks đơn giản để thực hiện, giữ mã của tôi được tổ chức và giữ cho bộ điều khiển của tôi ánh sáng. Nếu tôi đặt tất cả các lớp trong thư mục mô hình, nó sẽ không cảm thấy có tổ chức đủ cho tôi (chỉ là một điều cá tính). Tôi cũng muốn có tùy chọn để hiển thị các dịch vụ web cho ứng dụng của mình, do đó, điều này làm cho tất cả cùng một logic, mô hình và quyền truy cập dữ liệu có sẵn cho các dịch vụ đó.

Answer 6

Đôi khi có thể có ý nghĩa khi có thư mục Mô hình trong dự án Trang web MVC của bạn VÀ cũng có một dự án riêng để lưu trữ Mô hình dữ liệu. (mặc dù điều này có thể chỉ có ý nghĩa nếu bạn có một nền tảng khá lớn mà bạn đang làm việc với các dự án khác sử dụng lại các thư viện phổ biến).

Một ví dụ trông như thế này:

Dự án:

• đề xuyên suốt: chứa tất cả các giao diện chung cho chuyển giao dữ liệu các đối tượng xung quanh giữa các dịch vụ khác, cũng như các hoạt động an ninh liên quan đến và các lớp

• Kinh doanh: chứa các đối tượng và lớp hoạt động của doanh nghiệp, kiểm soát quyền truy cập vào các hoạt động thông qua các yêu cầu bảo mật (đầu vào và đầu ra chỉ sử dụng Giao diện CrossCutting).

• dữ liệu: chứa Models dữ liệu để truy cập dữ liệu từ các dịch vụ khác/cơ sở dữ liệu (sử dụng bởi dự án kinh doanh)

• WebAPI: (dự án MVC) chứa một thư mục Models. Một số đối tượng mô hình có thể là các vật liệu tổng hợp của các giao diện CrossCutting để hỗ trợ các hoạt động web RESTful hiệu quả tối đa (vì vậy, một cuộc gọi HTTP duy nhất tới API web nhưng có thể dẫn đến nhiều cuộc gọi BLL).