2011-11-17 46 views
5

Tôi thường tự hỏi về cách đúng để thực hiện việc này:Lưu trữ dữ liệu Const thứ bậc

Ví dụ, trong chương trình của tôi có khoảng 100 hằng số (hoặc enums) được sử dụng trong một số phép tính. Chúng nên được lưu trữ ở một nơi. Chúng có thể được phân nhóm theo thứ bậc, ví dụ:

System3/Rules/Rule7/ParameterXY/MaxAverageValue 

Đương nhiên, tôi muốn các giá trị này có thể truy cập được khi mã hóa, vì vậy không thực sự là một lựa chọn.

Theo như tôi có thể nói, điều này có thể được thực hiện với:

  • tên liên tục rất lâu
  • lớp làm tổ
  • namespace

Sử dụng tên khá xấu xí, và nó không thực sự bảo trì tốt. Tôi tìm thấy các lớp làm tổ một cách tốt đẹp để làm điều đó, nhưng một số quy tắc stylecop/fxcop cấm điều đó, vì vậy điều này phải là "xấu" theo một cách nào đó. Cuối cùng, tôi tìm thấy các thay thế được đề xuất, sử dụng không gian tên, không phải là khủng khiếp tốt đẹp không. Imho nó tạo ra khối lượng của các thư mục và tập tin mà mỗi chứa hầu như không có gì. Và tôi không thích khi 50 không gian tên phụ bật lên trong bộ phản xạ lắp ráp.

Vì vậy, .. làm thế nào để bạn thực hiện loại công việc này? Bạn đề nghị điều gì?

+1

Tôi sẽ đề xuất không gian tên. Tránh các lớp lồng nhau và các tên hằng số dài.Thật khó để đọc được –

+0

MVC sử dụng các lớp học được tạo ra với các trường công lập const tĩnh IIRC – sehe

+0

@StevenMuhr: Tại sao bạn nói rằng các lớp lồng nhau khó đọc ra? Trên đỉnh đầu tôi đánh tôi như một giải pháp mà tôi muốn. Có nghĩa là bạn có thể giữ tất cả các hằng số của mình trong một tệp và bạn nhận được cấu trúc phân cấp giống như với các không gian tên. – Chris

Trả lời

4

tên liên tục rất lâu

Đây là loại gộp, nhưng ít nhất nó là có thể phát hiện. Tất cả các mã của bạn sẽ cư trú trong cùng một vị trí, do đó bạn sẽ không có một vấn đề tìm kiếm nó.

Tôi thấy lớp học làm tổ một cách tốt đẹp để làm điều đó, nhưng một số quy tắc StyleCop/FxCop cấm đó, vì vậy đây phải là "xấu" trong một số cách

Một lý do đó là có hại vì tự động công cụ kiểm tra mã/tạo mã khó thực hiện hơn. Một lý do khác là khó khám phá chúng hơn với Intellisense.

Lý do quan trọng nhất điều này là xấu bởi vì một lớp lồng nhau nên được liên kết chặt chẽ trong ý nghĩa phụ thuộc hướng đối tượng để bố cục có ý nghĩa hợp lý. Trong tất cả, nhưng một số trường hợp hiếm gặp (ví dụ: Enumerator classes) sẽ không có ý nghĩa. Trong trường hợp của bạn nó cũng không có ý nghĩa bởi vì các lớp của bạn không thực sự có bất kỳ hành vi hoặc định hướng đối tượng nào cả - chúng chỉ là một hệ thống phân cấp của các hằng số.

Namespaces

Đối với vấn đề bạn mô tả, đây là cách tốt nhất để xử lý nó. Bạn nhận được ít lộn xộn nhất trên mỗi cấp và bạn nhận được Intellisense trong khi nhập để bạn có thể thấy những gì bạn đang thu hẹp xuống trong khi giảm dần thông qua phân cấp.

IMHO nó tạo ra khối lượng của các thư mục và các tập tin mà mỗi chứa hầu như không có gì

Nếu bạn thực sự cần một hồ bơi khổng lồ của các hằng số, và nó không có ý nghĩa để ràng buộc họ đến các bộ phận khác của bạn ứng dụng, sau đó đây là một trong những trường hợp hiếm hoi mà tôi muốn lạm dụng quy tắc một tệp cho mỗi lớp và một cặp cho mỗi không gian tên. Lý do duy nhất bạn thậm chí nhồi chúng vào các lớp là vì .Net không có hỗ trợ cho các biến toàn cầu.

Một gợi ý

Bạn có đối tượng tên miền cụ thể rằng những hằng số thuộc về để thay thế? Ví dụ. có bất kỳ logic nào liên quan đến lớp học System3/Rules/Rule7 không? Đó không phải là một số loại quy tắc kinh doanh thực tế mà bạn nên thể hiện với lớp riêng của mình?

Nếu bạn có thể sắp xếp mã để bạn có a thicker domain model, thì vị trí hợp lý nhất để đặt các hằng số của bạn là trên các lớp thể hiện logic miền tương ứng.

Nếu không có miền dày, bạn có quy tắc xử lý hoàn toàn chung và bạn dựa vào các hằng số để cung cấp logic cho công cụ kinh doanh, sau đó bạn có ứng dụng hướng dữ liệu. Điều này có nghĩa là bạn nên lưu trữ dữ liệu của mình trong các tệp cấu hình, chứ không phải trong mã.

+0

Cảm ơn lời đề nghị cuối cùng, điều đó thực sự dường như là cách để đi. Hạn chế duy nhất là nó làm cho nó khó khăn hơn cho ai đó không biết mã để tìm một hằng số cụ thể. Nhưng có một giải pháp thanh lịch cho rằng: ressource hoặc cấu hình các tập tin (hoặc thậm chí cái gì khác) và tài sản (nhận được những giá trị) thay vì consts. :) – Efrain

0

Cách tôi làm việc này là có một tệp được đóng dấu có tên là Constants.

nên

public sealed class Constants 
{ 

    //for e.g. 
    //Sessions 
    public const string APPSESSIONKEY = "AppType"; 

} 

Thần I sử dụng này trong phần còn lại của dự án của tôi và tầm quan trọng ở đây là những gì bạn sẽ đặt tên cho nó vì nó sẽ giúp bạn nhớ nó và có ý nghĩa khi bạn cần nó.

Bằng cách gọi nó trong mã của bạn.

Constants.AppSessionKey 

Bạn cũng có thể

Tạo một hội với mục đích duy nhất là để giữ giá trị không đổi cho dự án. Mỗi hội đồng khác sau đó nên tham khảo này. Sau DRY và KISS, vì việc thêm tham chiếu là đủ đơn giản. Vấn đề chính ở đây là biên dịch lại.

1

Tần suất mỗi lần tái sử dụng được lặp lại trong nhiều phương pháp? Bạn có thể xem xét sắp xếp lại các hằng số của mình. Nếu bạn vẫn thấy mình với số lượng lớn các hằng số, hãy thử đặt chúng trong một lớp tĩnh với các thuộc tính chỉ đọc.

Nếu bạn chỉ cần một nơi tốt để xem tất cả ở một nơi, bạn cũng có thể xem lưu trữ chúng trong tệp app.config và bạn có thể truy cập chúng thông qua AppSettings và lớp ConfigurationManager.

0

Chúng tôi sử dụng tệp Tài nguyên với mẫu T4 tùy chỉnh tạo ra phân cấp lớp tĩnh với các trường chuỗi chỉ đọc cho các giá trị.

Các khóa trong tệp Tài nguyên của chúng tôi được phân tách bằng '.' để xây dựng hệ thống phân cấp.

Chúng tôi có thể có các tệp tài nguyên riêng biệt được biên dịch thành một phân cấp lớp.

Tôi biết rằng các lớp lồng nhau không được khuyến nghị nhưng theo ý kiến ​​của tôi, đối với một tình huống như thế này, đó là giải pháp tốt nhất.

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