2010-01-20 27 views
8

Tôi đã đọc một số câu hỏi khác về chủ đề này (here, herehere), nhưng chưa thấy câu trả lời hay. Tôi đã phát triển chia sẻ công bằng các lớp truy cập dữ liệu trước và cá nhân thích sử dụng các lớp thể hiện thay vì các lớp tĩnh. Tuy nhiên, nó là nhiều hơn một sở thích cá nhân (tôi muốn kiểm tra đối tượng kinh doanh của tôi, và cách tiếp cận này làm cho mocking ra DAL dễ dàng hơn). Tôi đã sử dụng các lớp tĩnh để truy cập cơ sở dữ liệu trước đây, nhưng tôi đã luôn cảm thấy một chút không an toàn trong sự phù hợp của một thiết kế như vậy (đặc biệt là trong một môi trường ASP.NET).Ưu điểm/khuyết điểm của việc lựa chọn giữa các lớp truy cập dữ liệu tĩnh và cá thể trong ứng dụng web là gì?

Bất cứ ai cũng có thể cung cấp một số ưu điểm/nhược điểm liên quan đến hai phương pháp tiếp cận này để phát triển các lớp truy cập dữ liệu với các nhà cung cấp ADO.NET (không có ORM), trong một ứng dụng ASP.NET nói riêng. Cảm thấy tự do để kêu vang trong nếu bạn có một số lời khuyên chung lớp tĩnh hơn so với trường hợp cụ thể là tốt.

Đặc biệt, vấn đề tôi quan tâm là:

  1. Threading & đồng thời
  2. Khả năng mở rộng
  3. Performance
  4. Bất kỳ ẩn số khác

Cảm ơn!

Trả lời

10

Phương pháp tiếp cận dựa trên tĩnh thực sự thường có một và chỉ một lợi thế chính: chúng dễ triển khai. phương pháp tiếp cận dựa

Instance giành cho:

  1. Threading và Concurrency - Bạn không cần bất kỳ/càng nhiều đồng bộ, vì vậy bạn sẽ có được thông lượng tốt hơn
  2. Khả năng mở rộng - các vấn đề Tương tự như trên
  3. Perf.- Các vấn đề Tương tự như trên
  4. Testability - Đây là dễ dàng hơn để kiểm tra, vì chế giễu ra một thể hiện rất dễ dàng, và thử nghiệm các lớp học tĩnh là phiền hà

phương pháp tĩnh có thể giành chiến thắng trên:

  1. Memory - Bạn chỉ có một ví dụ, vì vậy dấu chân thấp hơn
  2. Tính nhất quán/chia sẻ - Thật dễ dàng để giữ một cá thể duy nhất phù hợp với chính nó.

Nói chung, tôi cảm thấy rằng các cách tiếp cận dựa trên cá thể là cao hơn. Điều này trở nên quan trọng hơn nếu bạn cũng sẽ mở rộng ra ngoài một máy chủ đơn lẻ, vì cách tiếp cận tĩnh sẽ "phá vỡ" ngay sau khi bạn bắt đầu đưa nó vào nhiều máy ...

+0

Tôi nghĩ rằng những thuận xa hơn so với khuyết điểm, ít nhất là theo ý kiến ​​của tôi. Và đối với tiêu thụ bộ nhớ, tôi nghĩ rằng đó có lẽ là một nhược điểm không đáng kể trong hầu hết các ứng dụng. –

+0

@Kevin Babcock: Cá nhân tôi hầu như luôn cố gắng sử dụng các cách tiếp cận dựa trên cá thể. Nếu tôi muốn/cần tĩnh, tôi thường đi đến một singleton, vì đó là dễ dàng hơn để thích nghi với một multiton hoặc một cách tiếp cận dụ sau này (kể từ khi bạn vẫn làm việc với các trường hợp ...) –

+0

@ReedCopsey những gì về cho một lớp hữu ích làm công việc dọn dẹp cơ bản, như xác thực dữ liệu? –

5

Cảm giác chung của tôi là: Tại sao khởi tạo nếu bạn không phải làm vậy?

Tôi sử dụng các lớp tĩnh khi không có bất kỳ sử dụng nào cho nhiều phiên bản và không cần các thành viên ví dụ. Đối với DAL, vấn đề là chỉ có một. Tại sao khởi tạo nó nếu không có giá trị trong nó?

Nhìn vào this link, cho thấy rằng các cuộc gọi phương thức tĩnh nhanh hơn các cuộc gọi phương thức lớp mẫu.

This link cho thấy lợi thế của việc sử dụng lớp tĩnh là trình biên dịch có thể kiểm tra để đảm bảo rằng không có thành viên cá thể nào được thêm vào vô tình.

This link cho thấy rằng một lớp tĩnh có thể được sử dụng làm vùng chứa thuận tiện cho các tập hợp phương thức hoạt động trên tham số đầu vào và không phải nhận hoặc đặt bất kỳ trường nội bộ nào. Đối với một DAL, đây là chính xác những gì bạn có. Không có lý do gì để tạo ra bất kỳ trường nội bộ nào, và do đó, không có lý do để khởi tạo.

+0

Có rất nhiều giá trị khi khởi tạo. Cá nhân tôi cảm thấy hoàn toàn ngược lại: Chỉ đi tĩnh nếu có lý do thuyết phục cho loại/dữ liệu/phương pháp/etc được xử lý tĩnh. –

+0

Cảm giác chung của tôi là: Tại sao làm cho nó tĩnh khi bạn không cần? – Amy

+0

@yoda và @Reed: Bạn dường như cảm thấy rằng câu trả lời của tôi không chính xác. Theo ý kiến ​​của bạn, những nhược điểm của các lớp tĩnh là gì? –

0

Tôi đã sử dụng một tĩnh DAL trong nhiều năm, và tôi đồng ý với những lo lắng của bạn. Luồng và đồng thời là thách thức nhất và trong trường hợp của tôi, tôi lưu trữ các đối tượng kết nối khác nhau trong cấu trúc tĩnh luồng. Nó đã được chứng minh là rất khả năng mở rộng và hoạt động tốt, thậm chí nhiều hơn như vậy bây giờ mà tôi đang chuyển đổi PropertyInfo vào PropertyDescriptor mang lại cho tôi những lợi ích tương tự của sự phản ánh với hiệu suất tốt hơn. Trong DAL của tôi, tôi chỉ cần viết:

List<Entity> tableRows = SQL.Read(new SearchCriteria(), new Table()); 

Mọi thứ sinh ra lớp tĩnh SQL và làm cho mã của tôi đơn giản hơn rất nhiều.

+0

Bạn gặp phải sự cố đồng thời nào với cách tiếp cận của mình? –

+0

Cách tôi thiết lập nó tôi chạy một đối tượng kết nối cho mỗi chủ đề. Một vấn đề tương tranh mà tôi phải đối phó là khi bạn chèn một đối tượng mới, lấy khóa chính của nó (từ một chuỗi hoặc danh tính) và điền giá trị PK của đối tượng - nếu bạn không cẩn thận, bạn sẽ thực hiện nhiều lần chèn và nhận sai trình tự rối tung mối quan hệ FK. –

0

Đối với tôi, lý do chính là tôi không cần phải giữ trạng thái của đối tượng DAL đó. Trạng thái của các đối tượng mà nó sử dụng không mở rộng phạm vi của phương thức mà chúng được nhúng. Bằng cách này tại sao bạn sẽ giữ nhiều trường hợp của một đối tượng, nếu họ là tất cả như nhau?

Với phiên bản mới nhất của ADO.NET, có vẻ là cách thực hành tốt nhất để tạo và hủy kết nối tới cơ sở dữ liệu trong phạm vi cuộc gọi của bạn và để cho ConnectionPool xử lý toàn bộ vấn đề kết nối lại.

Một lần nữa với các phiên bản .NET Framework, TransactionScope mới nhất (sẽ là một lý do để tự quản lý kết nối của bạn) di chuyển đến cấp doanh nghiệp, cho phép bạn tham gia nhiều cuộc gọi tới DAL trong cùng phạm vi.

Vì vậy, tôi không thể xem trường hợp hợp tác để tạo và hủy (hoặc bộ nhớ cache) các phiên bản của DAL.

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