Có nên đưa logic kinh doanh vào Thủ tục lưu trữ hay không?

Luôn có một cuộc tranh luận về chủ đề này - "Có nên đưa logic kinh doanh vào Thủ tục lưu trữ hay không?". Nếu chúng tôi quyết định không sử dụng Công cụ ORM và không đưa Logic nghiệp vụ vào thủ tục lưu trữ thì chúng tôi sẽ đặt Logic nghiệp vụ ở đâu?

Trong các ứng dụng trước đây của tôi, tôi luôn ưu tiên chỉ đưa tất cả Logic nghiệp vụ vào các thủ tục được lưu trữ. Sau đó, từ mã .NET, tôi gọi các Quy trình được lưu trữ này bằng cách sử dụng Khối ứng dụng truy cập dữ liệu. SQLHelper, v.v. Nhưng đây không phải lúc nào cũng là kịch bản. Vì vậy, tôi đã làm một số googling nhưng cuối cùng trong bối rối .......

Có gợi ý nào không ...?

Tôi sẽ áp dụng một cách tiếp cận thực tế - về mặt lịch sử, 'lợi ích' chính của việc giữ logic kinh doanh trong các procs được lưu trữ là vì lý do hiệu suất (kiến trúc 2,5 tầng), trong khi tách logic kinh doanh thành tầng BLL (tầng 3 / N) thường sạch hơn với quan điểm bảo trì và dễ kiểm tra hơn (Mock / Stub out truy cập dữ liệu).

Tuy nhiên, do các ORMS .NET hỗ trợ LINQ như LINQ2Query, EF và NHibernate hiện tạo các truy vấn SQL được tham số hóa, trong đó các kế hoạch truy vấn có thể được lưu trong bộ nhớ cache, được thoát cho SQL Injection, v.v., tôi đoán rằng việc chuyển sang kiến ​​trúc tầng 3 / N là hấp dẫn hơn bao giờ hết và hầu hết các XUÂN (đặc biệt là các trung tâm truy vấn) có thể tránh được hoàn toàn. Các mẫu kho lưu trữ trong .NET thường hiển thị các tham số cây Biểu thức IQueryable / accept, cho phép truy cập an toàn nhưng linh hoạt vào các bảng của bạn. (Cá nhân trong các kiến ​​trúc kiểu SOA, tôi sẽ không đưa ra IQueryable ngoài BLL, tức là các tầng Dịch vụ và Trình bày của bạn nên hoạt động với một bộ phương thức được xác định rõ. Lý do là nếu không bạn không thể kiểm tra đầy đủ hệ thống của mình và bạn đã thắng '

Tuy nhiên, trong một hệ thống có kích thước khá, sẽ luôn có một vài trường hợp ngoại lệ, trong đó một đoạn mã thực sự dữ liệu có thể vẫn cần phải được viết dưới dạng Proc được lưu trữ vì lý do hiệu năng. Trong các trường hợp này, tôi sẽ giữ XUÂN và hiển thị XUÂN thông qua ORM, nhưng vẫn hiển thị chức năng như một phương thức chuyển qua trên BLL của bạn.

Trở thành một nhà phát triển java, sở thích của tôi là đưa logic kinh doanh vào BLL (kiểm soát nguồn dễ dàng và dễ dàng, quen thuộc, v.v.).

Tuy nhiên, sau khi làm việc cho một doanh nghiệp lớn có nhiều ứng dụng phân tán sử dụng các công nghệ khác nhau (C #, Java, Pick (không hỏi)), một lợi ích đáng kể của việc sử dụng các thủ tục được lưu trữ đã trở nên rõ ràng:

Thủ tục lưu trữ có thể được chia sẻ trên các ứng dụng khác nhau .

Nhóm của chúng tôi có một quy tắc mềm ở đây. Đôi khi, tốt hơn là giải quyết Logic nghiệp vụ trong T-SQL, đôi khi làm điều đó dễ dàng hơn trong c # (Lớp nghiệp vụ).

Vì vậy, chúng tôi có một giải pháp thực tế: Đặt nơi phù hợp hơn. Tôi biết lý thuyết đôi khi rất nghiêm ngặt về nó ... nhưng đó là lý thuyết :-)

Có những lợi thế và bất lợi cho cả hai (theo ý kiến ​​của tôi):

Các thủ tục được lưu trữ có thể trở thành một cơn ác mộng nếu bạn không sử dụng một số loại kiểm soát nguồn SQL (mà rất nhiều nơi không có) và bạn có nhiều nhà phát triển làm việc trên chúng. Ai đó có thể thay đổi một thủ tục được lưu trữ và quên cập nhật mã gọi thủ tục đó và trước khi bạn biết nó vừa xây dựng và triển khai một trang web sẽ đưa ra các ngoại lệ chưa được xử lý (tham số đếm không khớp, v.v.).

Mặt khác, các quy trình được lưu trữ cho phép sửa lỗi nhanh hơn trong các tình huống nhất định. Nếu có một lỗi với một thủ tục được lưu trữ, bạn chỉ cần sửa nó và bạn đã hoàn tất. Một sửa lỗi trong ORM yêu cầu xây dựng lại. Tùy thuộc vào quá trình xây dựng của bạn, điều này có thể kéo dài / gây phiền nhiễu.

Chúng tôi luôn đặt Logic nghiệp vụ của mình trong Lớp logic nghiệp vụ. Nếu bạn đặt nó trong Thủ tục lưu trữ, nó sẽ bị mất khi bạn thay đổi RDBMS.

"Logic kinh doanh" là một thuật ngữ mơ hồ. Tôi có nghĩa là nó không có một định nghĩa duy nhất. Một nguyên tắc nhỏ là giảm thiểu giao tiếp giữa các tầng khi bạn có thể. Vì vậy, bạn không cần phải gửi tên khách hàng trống đến máy chủ để kiểm tra trước khi chèn một hàng.

Có những trường hợp, khi một quy tắc dựa trên cơ sở dữ liệu đọc. Giả sử bạn muốn chuyển tiền từ Tài khoản 1 sang Tài khoản 2. Bạn cần đọc cả hai tài khoản, đảm bảo rằng chúng ở trạng thái tốt và số tiền trong Tài khoản 1 là đủ. Trong trường hợp này, máy chủ là ứng cử viên tốt hơn cho quy tắc này vì máy khách (là BL ở đây) không cần phải thực hiện 3 cuộc gọi đến tầng cơ sở dữ liệu cho quy trình này.

Tất nhiên, nếu bạn cần giải pháp của mình độc lập với cơ sở dữ liệu, hãy tạo các procs được lưu trữ chỉ cho CRUD (nếu được sử dụng).

Logic nên có trong BLL luôn vì:

• Nó có thể được kiểm tra đúng
• Khi SQL 20XX trở nên lỗi thời và bạn cần thay đổi sang phiên bản mới nhất, bạn không phải viết lại mã của mình.
• Mọi người không muốn thực hiện các thay đổi nhanh chóng (dường như được đưa ra như một cuộc tranh luận CHO SP)
• SP, theo kinh nghiệm của tôi, là điểm lớn nhất của lỗi nhà phát triển, đặc biệt là sau một vài thế hệ bảo trì / thay đổi.

Tôi tin rằng nên có luật quy định rằng sau khi SP dài hơn X dòng, nó không hoạt động như dự định.

Chúng tôi tạo một lớp dịch vụ chứa tất cả logic nghiệp vụ của chúng tôi được triển khai bằng ngôn ngữ đã chọn và chỉ sử dụng cơ sở dữ liệu cho các truy vấn. Cách tiếp cận này được chúng tôi ủy quyền vì mục tiêu của chúng tôi là tạo ra các giải pháp COTS để cung cấp các ứng dụng với các triển khai cơ sở dữ liệu khác nhau. Hibernate đã được chứng minh là cứu cánh cho chúng ta trong những trường hợp này.

Tôi nghĩ rằng ưu điểm lớn nhất của phương pháp này, ngoài tính di động của cơ sở dữ liệu, là bạn có thể tìm thấy tất cả các câu trả lời của mình trong một tìm kiếm.

Ngoài ra, mặc dù có một số câu trả lời cho một diễn đàn, tôi có một người bạn làm việc cho một công ty bảo hiểm may mắn 100 người đã thực hiện 2 chuyển đổi cơ sở dữ liệu trong ba năm vì cơ sở dữ liệu lựa chọn cho công ty đã thay đổi.

Theo kinh nghiệm hạn chế của tôi, tôi thích duy trì tính toàn vẹn dữ liệu với các thủ tục được lưu trữ và các tính năng cơ sở dữ liệu khác. Ví dụ: nếu tôi đang thực hiện chuyển tiền giữa hai tài khoản, tôi sẽ viết một thủ tục được lưu trữ. Tôi thấy nó có giá trị để có thể sử dụng nhiều ngôn ngữ ứng dụng.