6

Tôi có một ứng dụng thực hiện các phép tính phức tạp cho các thành viên. Mỗi thành viên có thể có nhiều tiểu bang của Hoa Kỳ được liên kết với tiểu sử của họ. Mỗi tiểu bang có các tính toán khác nhau cho mỗi khóa học mà một thành viên hoàn thành.Lớp nghiệp vụ so với SQL Server

Hiện tại tôi đã thực hiện các phép tính trong DB (SQL Server 2008) và sau đó gửi dữ liệu trở lại lớp ứng dụng, nơi họ có thể xem lịch sử của họ và sau đó tải xuống chứng chỉ cho mỗi khóa học.

Tôi có lớp logic kinh doanh nhưng không có nhiều điều xảy ra ở đó. Tôi biết điều này đã được hỏi rất nhiều nhưng bạn nghĩ tôi nên thực hiện những tính toán này ở đâu: lớp kinh doanh hoặc cơ sở dữ liệu? Tôi sẽ trở lại và ra !!

+7

Tôi sẽ luôn thực hiện các phép tính trong cơ sở dữ liệu, ** nếu ** tính toán của bạn sẽ cần phải trả về ** rất nhiều dữ liệu ** cho tầng giữa, chỉ để có ví dụ: một 'SUM' được tính toán. Tại sao bận tâm gửi tất cả dữ liệu đó xung quanh ?? Cơ sở dữ liệu được trang bị tốt để tổng hợp một số giá trị và chỉ gửi lại một kết quả - ** nhiều ** hiệu quả hơn! Vì vậy, bất cứ khi nào bạn cần phải làm rất nhiều - nhưng trở lại ít - làm điều đó trên máy chủ. –

+2

Tôi đồng ý với @marc_s SQL Server được thiết kế để xử lý dữ liệu nhanh chóng và hiệu quả hơn. –

Trả lời

6

tôi về cơ bản sẽ làm bất cứ điều gì trong SQL Server:

  • hiện rất nhiều cách tổng hợp, đếm, trung bình vv của dữ liệu và trả về chỉ có một giá trị duy nhất. Thực sự không có điểm nào khi chuyển khối lượng lớn dữ liệu sang tầng giữa, chỉ cần tổng hợp một cột

  • thực hiện rất nhiều thao tác dựa trên hàng/bộ; nếu bạn cần sao chép, chèn, cập nhật nhiều dữ liệu, một lần nữa, thực sự không có điểm nào trong việc kéo tất cả dữ liệu đó vào tầng giữa và sau đó gửi tất cả trở lại máy chủ - thực hiện nó ngay trên máy chủ. Ngoài ra: T-SQL là nhanh hơn đáng kể trong việc đối phó với các hoạt động thiết lập dựa trên (như xáo trộn dữ liệu xung quanh) so với bất cứ điều gì trong lớp giữa của bạn có thể

Tóm lại: cố gắng tránh gửi khối lượng lớn dữ liệu cho khách hàng/tầng lớp trung gian/kinh doanh trừ khi bạn hoàn toàn phải (ví dụ vì bạn muốn tải xuống tệp được lưu trữ trong cơ sở dữ liệu hoặc nếu bạn thực sự cần cần có để có 200 hàng đó được hiển thị thành đối tượng trong ứng dụng của bạn trên)

Một tính năng thường bị bỏ qua là cột được tính ngay trong bảng cơ sở dữ liệu của bạn - những thực sự tốt ở ví dụ tổng hợp tổng số đơn đặt hàng cộng với thuế và giao hàng thành tổng số tiền lớn, hoặc chúng là tuyệt vời để đặt cùng họ và tên của bạn vào tên hiển thị. Những thứ đó thực sự không nên được xử lý chỉ trong lớp logic nghiệp vụ - nếu bạn thực hiện những điều đó trong cơ sở dữ liệu trực tiếp, những giá trị "được tính toán" này cũng có sẵn cho bạn khi bạn kiểm tra các bảng cơ sở dữ liệu và xem dữ liệu trong SQL Server Mgmt Studio ...


tôi sẽ đặt nó vào lớp lớp giữa/logic kinh doanh

  • nếu nó đòi hỏi kiểm tra mở rộng logic, chuỗi phân tích cú pháp, phù hợp với mô hình và vân vân; T-SQL hút vào những điều

  • nếu nó đòi hỏi những thứ như gọi một dịch vụ web để có được một số dữ liệu để xác nhận dữ liệu của bạn chống lại, hoặc một cái gì đó như thế

  • nếu nó đòi hỏi nhiều hơn một hoạt động logic kinh doanh (chứ không phải là nghiêm ngặt "nguyên tử" hoạt động cơ sở dữ liệu)

Nhưng đó chỉ là "thô" Hướng dẫn - nó luôn luôn là một quyết định thiết kế cho từng trường hợp, và tôi không tin vào quy tắc nghiêm ngặt; mileage của bạn có thể thay đổi, từ trường hợp này sang trường hợp khác - vì vậy hãy chọn một cách tiếp cận phù hợp nhất cho bất kỳ tác vụ cụ thể nào trong tầm tay.

0

Nó giúp không có mã logic nghiệp vụ bên trong cơ sở dữ liệu (thủ tục được lưu trữ). Nó là tốt hơn để có nó trực tiếp trong ứng dụng để nó phù hợp ngay trong kiến ​​trúc. Mã SQL này chứa logic nghiệp vụ của bạn và không có gì sai với nó. (Không có gì sai khi có dữ liệu hoặc mã liên quan đến bảo trì trong sprocs).

Nếu lớp logic nghiệp vụ của bạn không hoạt động nhiều và chỉ chuyển dữ liệu từ SQL Server đến người gọi, có thể bạn không cần nó chút nào.

+1

Các thủ tục được lưu trữ có thể rất hữu ích - miễn là chúng xử lý các hoạt động cơ sở dữ liệu và không "ẩn" logic nghiệp vụ. Nhưng đối với rất nhiều hoạt động, có một thủ tục lưu trữ có thể rất hữu ích. Tôi sẽ không chỉ toàn cầu "cấm" họ –

+1

Bạn nói đúng. Cám ơn các bạn, – usr

+0

Cảm ơn các bạn, Về cơ bản khi tôi thu thập dữ liệu về những gì khóa học đã tham dự, tôi gửi lại báo cáo cho thành viên cho mỗi tiểu bang họ đăng ký cùng với tất cả các khoản tín dụng của họ. Tôi tin rằng DB là nơi chính xác để thực hiện các tính toán này. Đó là một người vb.net/c# thuần túy khiến tôi băn khoăn liệu tôi có làm điều này đúng không. Tất nhiên anh ta duy trì nó tất cả nên được thực hiện tại BLL. Mỗi tình huống là khác nhau. – mick

0

Lớp logic nghiệp vụ không có để thực hiện việc nâng hạng nặng, mục đích của nó là cung cấp sự trừu tượng hóa với các thực thể bằng ngôn ngữ của chủ đề. Do đó, lớp nghiệp vụ có thể được sử dụng để cung cấp cách tiếp cận được chia sẻ và nhất quán cho mọi lớp/ứng dụng cần thiết để làm việc trong không gian đó.

Để tạo ra nhiều thứ để làm cho một điểm, mục tiêu cuối cùng sẽ là lớp logic nghiệp vụ được sử dụng trên một tổ chức cho tất cả các ứng dụng hoạt động trong không gian chủ đề đó. I E. bọc trong một dịch vụ, vv

Trong thế giới thực của các ứng dụng nhỏ để làm điều này hoặc điều đó, lớp logic nghiệp vụ cảm thấy như một phụ lục một số lần. Bí quyết cũng cần nhớ rằng bất kỳ trường hợp sử dụng nào cũng phải được thực hiện như là các bài kiểm tra đối với lớp nghiệp vụ, cho bạn một cách khác để nghĩ về giao diện công cộng của nó.

Cách lớp logic kinh doanh được thực hiện công việc phải được ẩn khỏi các phần của ứng dụng gọi đó.

Do đó, nó hoàn toàn có thể chấp nhận để tính toán dữ liệu theo cách hiệu quả nhất (ví dụ: sql), miễn là các tính toán này được đưa ra một biểu diễn thích hợp trong lớp logic nghiệp vụ.