Các thủ tục lưu trữ có vi phạm phân tách ba tầng không?

Một số đồng nghiệp của tôi đã nói với tôi rằng có logic nghiệp vụ trong các thủ tục được lưu trữ trong cơ sở dữ liệu vi phạm kiến ​​trúc phân tách ba tầng, vì cơ sở dữ liệu thuộc về lớp dữ liệu trong khi các thủ tục được lưu trữ là logic nghiệp vụ.

Tôi nghĩ rằng thế giới sẽ là một nơi rất nghiệt ngã nếu không có thủ tục lưu trữ.

Họ có thực sự vi phạm sự phân chia ba tầng?

Đồng nghiệp của bạn đang kết hợp kiến ​​trúc với việc thực hiện.

Ý tưởng đằng sau một ứng dụng nhiều tầng chỉ đơn giản là nó được chia thành các phần đóng gói một số loại xử lý (lưu trữ, logic nghiệp vụ, trình bày) và giao tiếp với nhau bằng các giao diện được xác định rõ. Cũng giống như có thể thực hiện thành công những việc giống như lập trình hướng đối tượng trong các ngôn ngữ không hướng đối tượng, có thể thực hiện tương tự với nhiều tầng trong một môi trường, chẳng hạn như máy chủ cơ sở dữ liệu. Những gì làm một trong những thành công có điểm chung là cần phải được chăm sóc, kỷ luật và hiểu biết về các thỏa hiệp liên quan.

Hãy xem xét một ứng dụng ba tầng trong đó hai trong số các tầng đã được triển khai trên cơ sở dữ liệu:

• Dữ liệu Tier: Gồm các bảng cơ sở dữ liệu truy cập bằng cách sử dụng bốn hoạt động bảng tiêu chuẩn ( INSERT, UPDATE, DELETEvà SELECT).
• Tầng logic: Bao gồm các thủ tục được lưu trữ chỉ thực hiện logic nghiệp vụ và truy cập vào tầng dữ liệu chỉ bằng các phương pháp được nêu ở trên.
• Tầng trình bày: Bao gồm một máy chủ web đang chạy mã truy cập vào tầng logic bằng cách chỉ thực hiện các cuộc gọi thủ tục được lưu trữ.

Đây là một mô hình hoàn toàn chấp nhận được, nhưng nó đi kèm với một số sự đánh đổi. Logic nghiệp vụ được triển khai theo cách cho phép truy cập nhanh, dễ dàng vào tầng dữ liệu và có thể cho phép thực hiện những việc cần phải thực hiện "một cách khó khăn" bởi tầng logic bên ngoài cơ sở dữ liệu. Những gì bạn từ bỏ là khả năng dễ dàng chuyển cấp bậc sang một số công nghệ khác và triển khai vô tư (nghĩa là bạn phải hết sức cẩn thận rằng các tầng không sử dụng các phương tiện có sẵn trong cơ sở dữ liệu nhưng bên ngoài giao diện đã xác định của chúng) .

Có hay không loại điều này và sự đánh đổi mà nó mang lại có thể chấp nhận được trong một tình huống nhất định là điều bạn và đồng nghiệp phải xác định bằng cách sử dụng phán đoán của mình.

Các thủ tục được lưu trữ đủ mạnh để cho phép bạn viết mã vi phạm phân tách ba lớp bằng cách đưa logic nghiệp vụ vào lớp RDBMS. Tuy nhiên, đây là quyết định của bạn, không phải là một lỗ hổng cố hữu của các thủ tục được lưu trữ. Bạn có thể giới hạn SP của mình để phục vụ nhu cầu của lớp dữ liệu, trong khi vẫn giữ logic ứng dụng của bạn trong lớp ứng dụng của kiến ​​trúc.

Có một ngoại lệ hiếm gặp nhưng quan trọng đối với quy tắc phân tách, khi bạn cần các thủ tục được lưu trữ (cụ thể là một nhóm các trình kích hoạt) để chứa logic nghiệp vụ. Điều này xảy ra khi ứng dụng của bạn cần tạo ra nhiều tập hợp dữ liệu nhanh chóng chạm vào hàng triệu hàng. Trong trường hợp như vậy, các trình kích hoạt có thể được thiết lập để duy trì dữ liệu tổng hợp trước để sử dụng lớp nghiệp vụ. Điều này chỉ nên được thực hiện trong các tình huống khi không có tổng hợp trước, ứng dụng của bạn sẽ chậm được chấp nhận.

Lời khuyên của Atwood từ năm 2004 vẫn còn đúng cho đến ngày nay, chỉ có chúng ta bây giờ cũng có lợi ích của ORM.

http://blog.codinghorror.com/who-need-stored-procedures-anyways/

Các thủ tục lưu trữ nên được coi là ngôn ngữ lắp ráp cơ sở dữ liệu: chỉ được sử dụng trong các tình huống quan trọng nhất về hiệu năng. Có rất nhiều cách để thiết kế một lớp truy cập dữ liệu hiệu suất cao, vững chắc mà không cần dùng đến Thủ tục lưu trữ; bạn sẽ nhận ra rất nhiều lợi ích nếu bạn gắn bó với SQL được tham số hóa và một môi trường phát triển mạch lạc duy nhất.

Tóm tắt ngắn gọn: Nó thực sự phụ thuộc vào việc bạn sử dụng các thủ tục lưu trữ và yêu cầu kinh doanh.

Có một số dự án sử dụng kiến ​​trúc ba tầng và tùy thuộc vào bản chất của yêu cầu kinh doanh, có thể cần phải chuyển một số hoạt động sang tầng dữ liệu.

Nói về thuật ngữ, nói chung, các tầng này được mô tả là:

• Tầng trình bày hoặc lớp dịch vụ người dùng - cung cấp cho người dùng quyền truy cập vào ứng dụng.
• Tầng trung lưu , hoặc lớp dịch vụ kinh doanh - bao gồm các quy tắc kinh doanh và dữ liệu.
• Tầng dữ liệu hoặc lớp dịch vụ dữ liệu - tương tác với dữ liệu liên tục thường được lưu trữ trong cơ sở dữ liệu hoặc trong bộ lưu trữ vĩnh viễn.

Thông thường đối với kiến ​​trúc nhất định, tầng trung lưu hoặc lớp dịch vụ kinh doanh, bao gồm các quy tắc kinh doanh và dữ liệu. Tuy nhiên, đôi khi nó tạo ra sự khác biệt lớn để thay đổi các hoạt động cơ sở tập hợp nặng và / hoặc quy tắc dữ liệu được thực hiện trong tầng dữ liệu - thông qua tập các thủ tục được lưu trữ.

Những lợi ích của thiết kế ba tầng là:

Trong vòng đời của một ứng dụng, cách tiếp cận ba lớp cung cấp các lợi ích như khả năng sử dụng lại, tính linh hoạt, khả năng quản lý, khả năng bảo trì và khả năng mở rộng. Bạn có thể chia sẻ và tái sử dụng các thành phần và dịch vụ bạn tạo và bạn có thể phân phối chúng trên một mạng máy tính khi cần. Bạn có thể chia các dự án lớn và phức tạp thành các dự án đơn giản hơn và giao chúng cho các lập trình viên hoặc nhóm lập trình khác nhau. Bạn cũng có thể triển khai các thành phần và dịch vụ trên máy chủ để theo kịp các thay đổi và bạn có thể triển khai lại chúng khi tăng trưởng cơ sở người dùng, dữ liệu và khối lượng giao dịch của ứng dụng.

Vì vậy, nó thực sự là một cách tiếp cận dựa trên trường hợp có sự đánh đổi trong chính nó. Tuy nhiên, các nguyên tắc thiết kế của Microsoft về Mô hình kiến ​​trúc ba tầng khuyên bạn nên giữ logic kinh doanh của mình ở mức trung bình.

Cấp thực sự có nghĩa là máy khác nhau, lớp có nghĩa là tách biệt logic khác nhau. Với các thủ tục được lưu trữ, bạn có lớp dữ liệu và (ít nhất là một phần) lớp logic nghiệp vụ trong cùng một lớp. Đưa logic kinh doanh vào các thủ tục được lưu trữ vi phạm kiến ​​trúc 3 mệt mỏi nhưng có thể đặt câu hỏi liệu nó có vi phạm kiến ​​trúc 3 lớp hay không; một điều chắc chắn là nó chắc chắn không phải là một ví dụ tốt về sự tách biệt các mối quan tâm.

Một lớp là một cơ chế cấu trúc logic cho các yếu tố tạo nên giải pháp phần mềm của bạn; một lớp là một cơ chế cấu trúc vật lý cho cơ sở hạ tầng hệ thống. ( Tham khảo )

Theo tôi, có hai vấn đề lớn với việc xây dựng logic kinh doanh trong cơ sở dữ liệu:

1. Mã và thư viện: bạn sẽ thấy ít lập trình viên có khả năng lập trình bằng SQL, PL / SQL, TSQL, v.v. so với C #, Java, v.v. Ngôn ngữ lập trình cũng có lợi thế về IDE tuyệt vời, thư viện và khung công tác tuyệt vời.

2. Khả năng mở rộng theo chiều ngang: cách duy nhất bạn có thể mở rộng hệ thống của mình là bằng cách thay đổi máy chủ vật lý mà cơ sở dữ liệu có cơ sở dữ liệu mạnh hơn, khá tốn kém (máy chủ có RAM 64 GB); cơ sở dữ liệu quan hệ quy mô theo chiều ngang rất xấu, và thậm chí với chi phí lớn hơn. Trong khi, với logic nghiệp vụ trong máy chủ được xây dựng OO, bạn có thể mở rộng theo chiều ngang khá tốt bằng cách đặt máy chủ trên nhiều nút (trong Java, nhiều máy chủ ứng dụng hỗ trợ điều này).

Chúng tôi đã có cuộc tranh luận này trong văn phòng của chúng tôi một vài lần trước đây, tôi ủng hộ Phát triển cơ sở dữ liệu, tôi có quan điểm về nó

1. Nếu bạn đang sử dụng Cơ sở dữ liệu Oracle, bạn nên sử dụng PL / SQL càng nhiều càng tốt, bởi vì chắc chắn các công ty đầu tư sẽ gắn bó với nhà tiên tri trong ít nhất 10 năm kể từ bây giờ. Trong khi trong các ứng dụng ngày hôm qua bạn đang sử dụng Oracle Forms, hôm nay là các mẫu Web .net, sau đó là MVC, thì ngày mai bạn sẽ sử dụng angularjs và chỉ cần apis đầy đủ. Nếu logic tối đa của bạn nằm trong cơ sở dữ liệu, bạn có thể dễ dàng di chuyển sang các công nghệ giao diện người dùng mới.
2. Phát triển cơ sở dữ liệu rất nhanh và hiệu quả rất hiệu quả. Chỉ để cung cấp cho bạn một triển vọng. Trong dự án của chúng tôi có 7 nhà phát triển ứng dụng và một nhà phát triển cơ sở dữ liệu và 80% logic nằm trong cơ sở dữ liệu.
3. Nếu bạn đang sử dụng oracle, bạn có thể sử dụng các tiện ích để trực tiếp chuyển đổi các thủ tục cơ sở dữ liệu của mình thành Resi Api đầy đủ.

Đối số mạnh nhất mà các nhà phát triển ứng dụng đưa ra là logic nghiệp vụ phải độc lập với cơ sở dữ liệu để bạn có thể dễ dàng thay đổi cơ sở dữ liệu. Tôi nghĩ rằng nếu một công ty đang sử dụng orory tại sao họ sẽ chuyển sang công nghệ khác thay vì cơ hội để ứng dụng logic lỗi thời được mong đợi hơn. Vấn đề chủ yếu là tài năng mới của tài nguyên cơ sở dữ liệu còn thiếu, hầu hết mọi người bắt đầu sẽ làm các trang web đơn giản nơi họ đang sử dụng mysql hoặc sqlserver. Những kẻ này sau đó trở thành khách hàng tiềm năng cao cấp và có cảm xúc gắn bó với lớp ứng dụng :) thậm chí họ không muốn hiểu hay tranh luận.