lời khuyên về kiến ​​trúc các ứng dụng asp.net mvc

Question

Tôi đã sử dụng ASP.net MVC trong khoảng hai năm nay và tôi vẫn đang học cách tốt nhất để cấu trúc một ứng dụng.

Tôi muốn đưa ra những ý tưởng mà tôi đã thu thập và xem liệu chúng có "được chấp nhận" trong cộng đồng để thiết kế các ứng dụng MVC hay không.

Dưới đây là cách bố trí cơ bản của tôi:

• DataAccess Dự án - Chứa tất cả các lớp kho, LINQ-to-SQL bối cảnh dữ liệu, lọc, và các đối tượng kinh doanh tùy chỉnh cho kho phi MS SQL db (mà LINQ-to-SQL không tạo). Các kho lưu trữ thường chỉ có CRUD cơ bản cho đối tượng mà chúng đang quản lý.

• Dự án dịch vụ - Chứa các lớp dịch vụ thực hiện logic nghiệp vụ. Họ nhận đơn đặt hàng từ bộ điều khiển và nói với kho lưu trữ những gì cần làm.

• UI Project - Chứa các kiểu xem và một số trình bao bọc xung quanh những thứ như Trình quản lý cấu hình (để kiểm tra đơn vị).

• Dự án MVC chính - Chứa bộ điều khiển và chế độ xem, cùng với javascript và css.

Đây có phải là cách tốt để cấu trúc ứng dụng ASP.NET MVC 2 không? Bất kỳ ý tưởng hoặc đề xuất nào khác?

Mô hình xem có được sử dụng cho tất cả đầu ra cho chế độ xem và nhập từ chế độ xem không?

Tôi đang hướng xuống đường tạo mô hình xem cho từng đối tượng kinh doanh cần hiển thị dữ liệu trong chế độ xem và biến chúng thành các lớp cơ bản với một loạt thuộc tính là tất cả các chuỗi. Điều này làm cho giao dịch với các quan điểm khá dễ dàng. Tầng dịch vụ sau đó cần quản lý các thuộc tính ánh xạ từ mô hình khung nhìn đến đối tượng nghiệp vụ. Đây là một nguồn của một số nhầm lẫn của tôi bởi vì hầu hết các ví dụ tôi đã nhìn thấy trên MVC/MVC2 không sử dụng một mô hình xem trừ khi bạn cần một cái gì đó giống như một hộp combo.

Nếu bạn sử dụng xác thực mô hình mới của MVC 2, bạn sẽ xác thực đối tượng viewmodel và không phải lo lắng về việc đặt thuộc tính xác thực vào đối tượng nghiệp vụ?

Làm cách nào để đơn vị kiểm tra loại xác thực này hoặc tôi không nên kiểm tra đơn vị rằng thông báo xác thực được trả về?

Cảm ơn!

Answer 1

Thú vị.

Một điều tôi làm khác là tôi chia dự án DataAccess khỏi dự án Tên miền của mình. Dự án miền vẫn chứa tất cả các giao diện cho kho của tôi nhưng dự án DataAccess của tôi chứa tất cả các triển khai cụ thể của chúng.

Bạn không muốn những thứ như DataContext bị rò rỉ vào dự án miền của bạn. Theo sau onion architecture tên miền của bạn không nên có bất kỳ sự phụ thuộc nào vào cơ sở hạ tầng bên ngoài ... Tôi sẽ xem xét DataAccess để có điều đó vì nó được gắn trực tiếp với cơ sở dữ liệu.

Tách chúng ra có nghĩa là miền của tôi không có phụ thuộc vào bất kỳ ORM hoặc cơ sở dữ liệu nào, vì vậy tôi có thể hoán đổi chúng dễ dàng nếu cần.

Chúc mừng,
Charles

Ps. Phụ thuộc dự án của bạn trông như thế nào? Tôi đã tự hỏi nơi để đặt ViewModels của tôi. Có lẽ một dự án giao diện người dùng riêng biệt là một ý tưởng hay, nhưng tôi không hoàn toàn chắc chắn rằng nó sẽ hoạt động như thế nào. Làm thế nào để chúng chảy qua các tầng dự án khác nhau của ứng dụng của bạn?