2010-06-08 26 views
10

Có bất cứ nhược điểm để một lớp học như:C# - Nhược điểm để Thiết lập giá trị ban đầu trong bản Tuyên ngôn

class Example1 
{ 
    protected string UserId = (string)Session["user"]; 
} 
//versus 

class Example2 
{ 
    protected string UserId; 
    public Example2() 
    { 
     UserId = (string)Session["user"]; 
    } 
} 

Nếu tôi luôn muốn thiết lập giá trị này được có bất cứ nhược điểm để example1?

UPDATE:
Session [ "user"] được thiết lập trong Global.asax session_start. Vì vậy, nếu điều này không thành công. Không có gì nên làm việc anyways.

+0

Phiên được khởi tạo? – ANeves

+0

cập nhật câu hỏi – BuddyJoe

+0

một trong những mục đích sử dụng fav của tôi về toán tử kết hợp UserId = (string) Session ["user"] ?? "0"; – kenny

Trả lời

5

Vấn đề lớn nhất của bạn là nếu điều này protected string UserId = (string)Session["user"]; không thành công. Bạn không có quyền truy đòi để làm suy giảm một cách duyên dáng. Bằng cách đặt nó vào hàm tạo, v.v. Bạn có thể kiểm tra phiên và đưa ra quyết định về việc cần làm.

Theo nguyên tắc chung, tôi chỉ thử và đặt các giá trị mà tôi biết sẽ thành công như UserId = -1; v.v ... và sau đó sửa đổi chúng trong một khối mã khi tôi cần. Bạn không bao giờ biết khi nào một cái gì đó sẽ đi sai và bạn cần phải phục hồi từ nó.

2

Nhược điểm chính là bạn chỉ có thể đặt giá trị bằng một câu lệnh. Ví dụ: nếu bạn muốn kiểm tra khóa Phiên tồn tại và nếu không, bạn muốn chỉ định giá trị đó, thì bạn không thể thực hiện điều đó bằng cách đặt giá trị ban đầu.

2

Nếu bạn kiểm tra trình gỡ lỗi, cài đặt của giá trị trong khai báo (Ví dụ 1) xảy ra trước khi hàm tạo được gọi, vì vậy bạn cần đảm bảo rằng nó không dựa trên bất kỳ thứ gì được thiết lập từ hàm tạo.

+0

Điểm tốt. Tôi sẽ nhớ kiểm tra các tình huống này +1 – BuddyJoe

1

Tôi thực sự khuyên bạn nên sử dụng dàn diễn viên "an toàn".

UserId = Session["user"] as string; 

Bằng cách này, nếu mục phiên không tồn tại hoặc không phải là chuỗi, bạn không thất bại. Bạn chỉ nhận được một null, mà bạn có thể kiểm tra trước khi sử dụng UserId.

+3

Truyền an toàn được sử dụng quá nhiều trong các tình huống như thế này. Nếu nó không phải là một chuỗi, tôi sẽ tưởng tượng rằng bạn có thể sẽ muốn có một lỗi. Bạn đang viết mã ở vị trí linh sam, và bạn đang mong đợi một chuỗi, vì vậy nếu nó không phải là một chuỗi, nó phải được nêu ra như một vấn đề cần được sửa. Tôi đã nhìn thấy quá nhiều hệ thống chứng minh hành vi kỳ lạ vì loại sai được lưu trữ ở đâu đó, và an toàn đúc ẩn các lỗi thực sự và làm cho nó trông giống như một lỗi biến uninitialized thay thế. Chỉ cần hai xu của tôi. –

+0

Nhận xét của anh ta (được thêm vào sau câu trả lời của bạn) làm cho một điểm mà 'Session [" user "]' * phải * là một chuỗi, vì vậy ngoại lệ sẽ là tốt nhất để giải quyết vấn đề trong chồi – STW

+0

. , bất cứ khi nào bạn biết rằng một ngoại lệ là có thể. Có lẽ nó là quyền để cho trường hợp ngoại lệ bay trong trường hợp này, nhưng cũng có thể, có thể không. Truyền an toàn cho bạn lựa chọn. –

1

AFAIK, không có sự khác biệt thực sự giữa khởi tạo giá trị nội tuyến và khởi tạo hàm tạo, ngoại trừ thứ tự thực hiện câu lệnh và thực tế bạn bị hạn chế nhiều đối với các câu lệnh đơn trong mã nội tuyến. Thứ tự thực hiện là khởi tạo giá trị được thực hiện trước bất kỳ logic của hàm tạo nào, theo thứ tự không cụ thể, vì vậy nếu bất kỳ câu lệnh khởi tạo nào xảy ra có các tác dụng phụ, bạn có thể gặp phải một số bất ngờ khó chịu. Tuy nhiên, nó được đảm bảo rằng mã đó sẽ chạy, vì vậy không có khả năng thêm một hàm tạo bổ sung sau này, và quên khởi tạo một số trường.

Tôi thích sử dụng (xích) các nhà xây dựng để khởi tạo nội tuyến, vì tôi thấy mã dễ đọc hơn theo cách đó và tôi cũng có thể thực hiện bất kỳ kiểm tra bổ sung nào có thể trở nên cần thiết trên đường.

0

Nguyên tắc tôi sử dụng: Sử dụng trình khởi tạo trường cho các giá trị cơ bản/được biết đến tại thời gian biên dịch. Nếu bạn đang làm một cái gì đó như tìm kiếm một bộ sưu tập toàn cầu hoặc một số logic không tầm thường, di chuyển nó vào ctor (để xử lý lỗi/phục hồi như những người khác đã chỉ ra).

Giả sử rằng bạn chắc chắn rằng sẽ không có sai sót, các

  • Ưu điểm: initializers lĩnh vực rất dễ đọc.
  • nhược điểm: nếu bạn có một loạt các trình khởi tạo trường và nhiều ctors, IL cho initializers sẽ được chèn ở trên cùng của mỗi cuống dẫn đến một số bloat IL. Vì vậy, trong trường hợp này, gọi phương thức Initialize like sẽ tốt hơn.

Ngoài ra, tôi không thấy bất kỳ nhược điểm nào đối với trình khởi tạo trường.

0

Thật khó để biết làm thế nào để bắt đầu nói rằng đó không phải là một ý tưởng tốt vì nhiều lý do. Phiên đầu tiên phải là biến toàn cầu, nếu không mã của bạn sẽ không biên dịch được. Tôi đoán Session trong ngữ cảnh của bạn ở đây là System.Web.HttpContext.Current.Session, vì vậy, mã của bạn thậm chí sẽ không biên dịch. Giả sử bạn có Session là một biến toàn cầu, thì bạn phải khởi tạo đúng nó và gán Session ["user"], vậy bạn sẽ làm như thế nào? Sau đó, bạn tạo sự phụ thuộc này giữa lớp của bạn và phiên, vì vậy làm thế nào để bạn kiểm tra đơn vị? Cộng với tất cả các lý do khác từ tất cả các câu trả lời khác.

0

Bạn có thể một ngày nào đó muốn có một hàm tạo thứ hai với một giá trị khác của UserId.

0

AFAIK hàm tạo luôn được gọi sau khi tất cả các trường được khởi tạo. Vì vậy, trong Ví dụ 2, trước tiên bạn sẽ khởi tạo trường thành Null và sau đó đến (string)Session["user"].

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