Có cần một lớp nhà máy để tạo viewmodels không?

Một đồng nghiệp của tôi đã đề xuất sử dụng một lớp nhà máy để tạo các đối tượng viewmodel trong các giải pháp ASP.NET MVC của chúng tôi. Ý tưởng là nó có thể giúp thiết kế và bảo trì, về cách thức chế độ xem được xây dựng trong các ứng dụng của chúng tôi.

Tôi muốn tìm hiểu xem có ai có kinh nghiệm về việc này không. Tôi đã thực hiện một số nghiên cứu và tìm thấy rất ít về thực hành này.

Hiện tại chúng tôi tạo các đối tượng viewmodel ở cấp điều khiển, vd

public ActionResult Index()
{
    return this.View(this.BuildIndexViewModel());
}

Vì vậy, cái này.BuildIndexViewModel () chịu trách nhiệm tạo lớp viewmodel (rõ ràng :). Nhưng chúng tôi đang xem xét khả năng của:

public ActionResult Index()
{
    return this.View(ViewModelFactory.CreateIndexViewModel());
}

Đây là một ý tưởng thú vị, nhưng tôi không bị thuyết phục 100%. Tôi đã quan tâm đến ý kiến của người khác về điều này.

design asp.net-mvc

— Jason Evans
nguồn

Tôi đấu tranh để thấy lợi ích phải trung thực. Bạn sẽ sử dụng một nhà máy để ẩn việc xây dựng các vật thể, nhưng tại sao bạn lại trong trường hợp này?

— CodeART

Phương thức BuildIndexViewModel của bạn đã là một phương thức xuất xưởng, có lẽ là riêng tư đối với bộ điều khiển. Lý do duy nhất để trích xuất điều đó đến một lớp nhà máy riêng biệt là sử dụng lại nó trong một bộ điều khiển khác.

— MattDavey

Cả hai bạn đều có chung suy nghĩ như tôi về điều này, vì vậy tôi rất vui vì tôi không cô đơn :) @MattDavey Tôi có thể thành thật nói rằng tôi nghi ngờ rất nhiều rằng các chế độ xem sẽ được sử dụng với nhiều bộ điều khiển, điều này tạo ra nhà máy ý tưởng dư thừa. Tôi sẽ chia sẻ điều này khi chủ đề xuất hiện trở lại trong công việc.

— Jason Evans

Cá nhân tôi thích loại viewmodel là chuyên gia về quá trình xây dựng chính nó. Thời gian duy nhất mà chuyên môn nên đặt ở nơi khác là nếu việc xây dựng đòi hỏi kiến thức về các lĩnh vực ứng dụng khác (ví dụ như kho lưu trữ), trong trường hợp đó bạn có thể muốn một người trung gian giữ cho khung

— nhìn im

@MattDavey: Bạn có thể gói hai bình luận đó thành một câu trả lời mà tôi có thể nêu lên không?

— pdr

Trong trường hợp này tôi sẽ nói hướng dẫn tốt nhất để tuân theo sẽ là các nguyên tắc GRASP . Cụ thể, xem xét bốn tiêu chí của việc tạo đối tượng tạo:

Nói chung, một lớp B phải chịu trách nhiệm tạo các thể hiện của lớp A nếu một, hoặc tốt hơn là, áp dụng sau đây

Trường hợp của B chứa hoặc tổng hợp các thể hiện của A
Trường hợp của bản ghi B của A
Trường hợp của B sử dụng chặt chẽ các trường hợp của A
Các thể hiện của B có thông tin khởi tạo cho các thể hiện của A và chuyển nó vào phần tạo.

Lớp trình điều khiển (B) của bạn khớp với các mục số 3 & # 4 của danh sách đó (và # 2 nếu chế độ xem được gửi lại), do đó, đây là nơi rất hợp lý để hành vi xây dựng của chế độ xem (A) tồn tại. Như tôi thấy, sẽ chỉ có hai lý do buộc tôi phải trích xuất hành vi xây dựng đó thành một lớp chuyên gia.

DRY - Nếu hai hoặc nhiều bộ điều khiển cần chia sẻ hành vi xây dựng khung nhìn, việc gói nó trong một thành phần riêng biệt sẽ tạo điều kiện cho việc sử dụng lại mã và tránh trùng lặp.
Nếu hành vi xây dựng có sự phụ thuộc vào các thành phần hệ thống khác như kho lưu trữ, trình xác nhận, v.v. và bạn không muốn giới thiệu khớp nối này với chính bộ điều khiển (theo thuật ngữ GRASP, chế tạo thuần túy).

Nhìn lại 4 tiêu chí tạo đối tượng đó trong GRASP, tôi sẽ chỉ trích xuất hành vi cho một nhà máy riêng nếu nó giành cho tôi thêm một đánh dấu vào danh sách đó. Nếu không thì sẽ không có giá trị gì khi làm như vậy.

Mong rằng sẽ giúp!

— MattDavey
nguồn