MVC + 3 tầng; ViewModels đi vào đâu?


11

Tôi đang thiết kế một ứng dụng 3 tầng bằng ASP.NET MVC 4. Tôi đã sử dụng các tài nguyên sau đây làm tài liệu tham khảo.

Tôi có desingn sau đây cho đến nay.

Lớp trình bày (PL) (dự án MVC chính, trong đó M của MVC được chuyển sang Lớp truy cập dữ liệu):

MyProjectName.Main
    Views/
    Controllers/
    ...

Lớp logic nghiệp vụ (BLL) :

MyProjectName.BLL
    ViewModels/
    ProjectServices/
    ...

Lớp truy cập dữ liệu (DAL) :

MyProjectName.DAL
    Models/
    Repositories.EF/
    Repositories.Dapper/
    ...

Bây giờ, PL tham chiếu BLL và BLL tham chiếu DAL. Cách này lớp dưới không phụ thuộc vào lớp trên nó.

Trong thiết kế này, PL gọi một dịch vụ của BLL. PL có thể chuyển Mô hình xem cho BLL và BLL có thể chuyển Mô hình xem lại cho PL.

Ngoài ra, BLL gọi lớp DAL và lớp DAL có thể trả lại Mô hình cho BLL. BLL có thể lần lượt xây dựng Mô hình xem và đưa nó trở lại PL.

Cho đến nay mô hình này đã làm việc cho tôi. Tuy nhiên, tôi đã gặp phải một vấn đề trong đó một số ViewModels của tôi yêu cầu tham gia vào một số thực thể. Trong cách tiếp cận MVC đơn giản, trong bộ điều khiển tôi đã sử dụng truy vấn LINQ để thực hiện joins và sau đó select new MyViewModel(){ ... }. Nhưng bây giờ, trong DAL tôi không có quyền truy cập vào nơi ViewModels được xác định (trong BLL).

Điều này có nghĩa là tôi không thể tham gia DAL và trả lại cho BLL. Có vẻ như tôi phải thực hiện các truy vấn riêng biệt trong DAL (thay vì tham gia trong một truy vấn) và sau đó BLL sẽ sử dụng kết quả của các truy vấn này để xây dựng ViewModel. Điều này rất bất tiện, nhưng tôi không nghĩ mình nên tiết lộ DAL với ViewModels.

Bất kỳ ý tưởng làm thế nào tôi có thể giải quyết tình trạng khó xử này? Cảm ơn.

Câu trả lời:


18

dự án MVC chính, nơi M của MVC được chuyển đến Lớp truy cập dữ liệu

Quan niệm sai lầm phổ biến. Các Msố MVCkhông có gì để làm với dữ liệu, mặc dù rất nhiều ví dụ và hướng dẫn mà tuyên bố như vậy.

M là ViewModel của bạn và sẽ nằm trong dự án MVC của bạn. ViewModels bạn có trong BLL của bạn thực sự được đặt tên là DataContuces hoặc BusinessModels.

Trong bộ điều khiển của bạn, bạn có một cái gì đó tương đương với điều này:

Get(id):
    dataContract = _service.Get(id);
    viewModel = Map(dataContract);
    return viewModel

Trong dịch vụ của bạn, một cái gì đó như thế này:

Get(id):
    dataModel = _dataAccess.Get(id);
    dataContract = Map(dataModel);
    return dataContract;

Và trong DataAccess, bạn thực hiện các phép nối đúng theo đối tượng được yêu cầu. Tuy nhiên, bạn hoàn toàn miễn phí khi thêm các phương thức tùy chỉnh vào DataAccess khi được yêu cầu, vì vậy dịch vụ của bạn có thể gọi các phương thức đó:

GetWithBars():
    dataModels = _repository.Query("select from foos join bars");
    return dataModels;
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.