2012-01-16 32 views
7

Tôi đang tạo chế độ xem cho mỗi màn hình trong ứng dụng ASP.NET MVC của tôi. Tôi đặt tất cả logic để tạo mô hình chế độ xem trong một lớp học builder. Thông thường, có logic đặc biệt để chuyển đổi các đối tượng dữ liệu thành các mô hình xem, bao gồm tổng hợp, lọc và sắp xếp. Mỗi người xây dựng được thông qua một bộ phụ thuộc phụ thuộc, là một đối tượng có chứa các thuộc tính cho mỗi phụ thuộc (kho, các nhà xây dựng khác, v.v ...).Quy ước đặt tên về mô hình xem để tránh tên dài

Vấn đề là tên của tôi đang nhận được thực sự dài. Một tập phụ thuộc thường sẽ có một cái tên sáng tác theo cách này:

xem mô hình tên + Builder + DependencySet

Xem mô hình thường có những cái tên sáng tác của bạn hiện đang ở và những đứa trẻ. Ví dụ: hệ thống của tôi có định nghĩa nhà cung cấp được phân loại. Vì vậy, để hiển thị các định nghĩa nhà cung cấp thuộc một thể loại, tôi có một mô hình điểm được gọi là:

CategoryProviderDefinitionListViewModel

Nó sẽ giống như thế này:

public sealed class CategoryProviderDefinitionListViewModel 
{ 
    public long CategoryId { get; set; } 
    public string CategoryName { get; set; } 
    public ProviderDefinitionViewModel[] ProviderDefinitions { get; set; } 
} 

Vì vậy, tôi người xây dựng được gọi là

CategoryProviderDefinitionListViewModelBuilder

Vì vậy, thiết lập sự phụ thuộc của tôi được gọi là

CategoryProviderDefinitionListViewModelBuilderDependencySet

Đó chỉ phù hợp trên màn hình. Những ngón tay nghèo của tôi mệt mỏi. Hơn nữa, một số màn hình gần như hiển thị cùng một dữ liệu, vì vậy các tên kiểu xem của chúng gần như giống nhau. Khi tôi xem qua thư mục của mình, thật khó để tìm ra các lớp mô hình xem cụ thể mà tôi đang tìm kiếm.

Lý tưởng nhất là tôi có thể nhóm các lớp mô hình chế độ xem của mình lại với nhau, liên kết chúng với (các) chế độ xem nơi chúng được sử dụng. Sẽ tốt hơn nếu tránh va chạm và đặt tên càng ngắn càng tốt, đồng thời giữ cho chúng có ý nghĩa. Có ai tìm thấy tổ chức quy ước/thư mục đặt tên hoạt động tốt trong trường hợp này không?

Trả lời

8

Tôi đã sử dụng hậu tố "ViewModel" một cách nhất quán trong một thời gian khá và trung thực, đôi khi tôi thấy nó thừa. Tôi nghĩ rằng chỉ cần nhóm tất cả các lớp này trong một không gian tên khác nhau là đủ.

sự hiểu biết của tôi là ước này đã được áp dụng để tránh sự va chạm giữa mô hình miền và các lớp học xem mô hình (ví dụ sản phẩm vs ProductViewModel). Tuy nhiên, vì các mô hình khung nhìn của bạn được đặt tên theo các màn hình, rất khó có khả năng bạn sẽ có một lớp có cùng tên trong mô hình miền của bạn. Trong thực tế, nó phải thực sự có vấn đề tại sao bạn có một lớp như vậy trong mô hình miền của bạn!:)

Vì vậy, nếu bạn đặt tên cho điểm mô hình một cái gì đó của bạn như ViewProduct (cho phép người dùng để xem/chỉnh sửa một sản phẩm), bạn không cần phải gọi nó ViewProductViewModel. Xem tôi sẽ đi đâu?

Do đó, lớp Trình tạo của bạn có thể được gọi đơn giản là ViewProductBuilder thay vì ViewProductViewModelBuilder.

Về tập hợp phụ thuộc của bạn, tôi không chắc lý do cơ bản của bạn đằng sau điều này là gì. Nhưng với tôi nó có vẻ không cần thiết. Nếu trình xây dựng của bạn có các phụ thuộc vào các đối tượng khác, bạn sẽ cần phải chèn các phụ thuộc vào hàm tạo của trình tạo, thay vì đóng gói chúng vào một lớp khác (DependencySet) và sau đó truyền chúng đi xung quanh.

Nếu bạn tìm thấy người xây dựng của bạn phụ thuộc vào quá có thể điều và đây là những gì bạn đang cố gắng để ẩn đằng sau DependencySet, sau đó nó có thể là dấu hiệu của một mùi thiết kế ở một nơi khác. Nếu các lớp và các phụ thuộc của chúng được thiết kế theo kiểu hướng đối tượng thích hợp, hành vi nên được phân phối rất độc đáo giữa các lớp khác nhau và không lớp nào có sự phụ thuộc vào quá nhiều thứ khác. Vì vậy, ẩn n phụ thuộc dưới 1 lớp (DependencySet) chỉ đơn thuần là điều trị các triệu chứng không phải là vấn đề chính nó.

Hope trợ giúp này :)

3

Tôi thích bài dàn xếp tỷ số tên ViewModel của tôi với "DTO". (Trường hợp DTO là viết tắt của đối tượng truyền dữ liệu, tức là một đối tượng không có gì nhưng chứa thông tin)

Điều này không chỉ để tránh tên dài. Nhưng nó cũng làm cho tôi có thể sử dụng cùng tên như Người dùng, nhưng nó sẽ được gọi là UserDTO, cho tôi biết rằng tôi đang làm việc với một đối tượng là một phần của ViewModel của mình.

+0

[DTO là một điều khác nhau] (http://stackoverflow.com/questions/1051182/what-is-data-transfer-object), để bắt đầu, có thể có DTO ** và * * xem các mô hình trong cùng một giải pháp. – Liam

+0

Đó là sự thật. Và nếu tình hình đó nảy sinh, tôi có lẽ cũng sẽ lựa chọn một quy ước đặt tên khác. Nhưng điểm tốt. – CodeMonkey

1

Tôi có xu hướng đồng ý với Mosh.

Hậu tố ViewModel trở nên dư thừa phần lớn thời gian và đôi khi bạn có thể có tên lớp khớp, nó khá dễ quản lý vì chúng được giới hạn trong không gian tên ViewModel của bạn. Tôi cũng thấy rằng việc sử dụng bí danh không gian tên kỳ lạ làm tổn thương bộ não của tôi ít hơn so với các tên lớp của tôi trên bảng.

Tất nhiên trong trình bày/bộ điều khiển của bạn, bạn có thể đã đặt ra xung đột, nhưng đó có thể là dấu hiệu cho thấy bạn cần đặt tên cho Chế độ xem phù hợp hơn, ví dụ: không phải người dùng mà là người dùng ViewUser/EditUser.

Đối với kết quả tìm kiếm và danh sách, tôi thấy tốt nhất là nên loại bỏ một số thứ như IEnumerable thay vì IEnumerable. Cái sau thường có nghĩa là bạn kết thúc với một lớp mô hình khung nhìn người dùng mà trở thành một nền tảng bán phá giá cho tất cả các thuộc tính người dùng có thể có hoặc không cần thiết trong toàn bộ dự án. Đây là một trong những điều quan trọng cần lưu ý và nếu bạn thấy mình có một lớp như thế này, bạn đã đi theo dõi ở đâu đó. Giữ quan điểm của bạn và xem mô hình mô tả và cụ thể. Nếu bạn có nhiều kiểu xem tương tự thì vấn đề có thể là vấn đề thiết kế lớn hơn; một số nhà thiết kế có xu hướng sáng tạo hơn là tái sử dụng các cấu trúc đồ họa hiện có.

Các vấn đề liên quan