Tại sao nhà phát triển nên sử dụng các dịch vụ web thay vì kết nối trực tiếp đến db? [đóng cửa]

Tôi đang tìm danh sách "top ten" lý do tại sao chúng ta nên kết nối với cơ sở dữ liệu từ xa thông qua dịch vụ web thay vì kết nối trực tiếp với db. Đây là một cuộc tranh luận nội bộ ngay bây giờ và tôi ủng hộ dịch vụ web nhưng thua cuộc. Tôi có một kiến ​​thức cơ bản về WCF / dịch vụ web, không ai khác làm. Chúng ta có thể làm bất cứ điều gì chúng ta muốn để tiến về phía trước nhưng chúng ta cần phải gắn bó với bất cứ điều gì chúng ta chọn.

Đây là những gì tôi đã nghĩ ra. Nữa không?

1. Các dịch vụ web WCF, nếu được định cấu hình đúng cách, có thể an toàn hơn.
2. Các thay đổi đối với DB chỉ cần được thực hiện ở mức dịch vụ (tệp cấu hình hoặc dịch vụ biên dịch lại).
3. Sau khi thiết lập và lưu trữ, các dịch vụ web sẽ dễ sử dụng hơn.

1. Bảo vệ. Bạn không cấp quyền truy cập DB cho bất kỳ ai ngoài máy chủ web / người dùng ứng dụng.

   Điều này cực kỳ quan trọng khi bạn có rất nhiều người dùng. Bạn tránh được nỗi đau của việc bảo trì người dùng / vai trò ở phía DB.

2. Giảm tải DB. Dịch vụ web có thể lưu vào bộ đệm dữ liệu mà nó truy xuất từ ​​DB.

3. Tổng hợp kết nối cơ sở dữ liệu (hat / tip @Dogs).

   Một dịch vụ web có thể sử dụng một nhóm nhỏ các kết nối DB được mở vĩnh viễn. Sự trợ giúp theo nhiều cách:

   • Nhóm kết nối DB bị giới hạn ở phía máy chủ cơ sở dữ liệu.

   • mở một kết nối DB mới là RẤT tốn kém (đặc biệt là đối với máy chủ cơ sở dữ liệu).

4. Khả năng chịu lỗi - dịch vụ có thể chuyển đổi giữa các nguồn dữ liệu chính / DR mà không cần người tiêu dùng dịch vụ thực hiện chi tiết về sự cố.

5. Khả năng mở rộng - dịch vụ có thể lan truyền các yêu cầu giữa nhiều nguồn dữ liệu song song mà không cần người tiêu dùng dịch vụ thực hiện chi tiết việc chọn tài nguyên.

6. Đóng gói. Bạn có thể thay đổi việc triển khai DB cơ bản mà không ảnh hưởng đến người dùng dịch vụ.

7. Làm giàu dữ liệu (điều này bao gồm mọi thứ từ tùy chỉnh máy khách đến bản địa hóa đến nội bộ hóa). Về cơ bản bất kỳ cái nào trong số này đều có thể hữu ích nhưng bất kỳ cái nào trong số chúng đều là tải trọng lớn trên cơ sở dữ liệu và thường rất khó triển khai bên trong DB.

8. Có thể áp dụng cho bạn hoặc không - một số quyết định về kiến ​​trúc không thân thiện với các tài khoản DB. Ví dụ: Máy chủ Java chạy trên Unix có thể dễ dàng truy cập vào cơ sở dữ liệu, trong khi một máy khách java chạy trên PC Windows không nhận biết được cơ sở dữ liệu cũng như bạn có thể không muốn.

9. Tính di động. Khách hàng của bạn có thể không sử dụng cùng một nền tảng / kiến ​​trúc / ngôn ngữ. Việc tạo lại một lớp truy cập dữ liệu tốt trong mỗi một trong số đó khó hơn (vì nó phải tính đến các vấn đề như chuyển đổi dự phòng nêu trên / v.v ...) hơn là xây dựng lớp người dùng cho một dịch vụ web.

10. Điều chỉnh hiệu suất. Giả sử giải pháp thay thế là khách hàng đang chạy các truy vấn của riêng họ (và không phải các thủ tục được lưu trữ sẵn), bạn có thể chắc chắn 100% rằng họ sẽ bắt đầu sử dụng các truy vấn ít hơn tối ưu. Ngoài ra, nếu dịch vụ web giới hạn tập hợp các truy vấn được phép, nó có thể giúp điều chỉnh cơ sở dữ liệu của bạn một cách đáng kể. Tôi phải nói thêm rằng logic này có thể áp dụng như nhau cho các thủ tục được lưu trữ, không phải duy nhất cho các dịch vụ web.

Bạn cũng có thể tìm thấy một danh sách tốt trên trang này: 'Đóng gói Truy cập Cơ sở dữ liệu: Một Thực hành "Tốt nhất" Agile "

Chỉ cần nói rõ - một số vấn đề này có thể không áp dụng được cho TẤT CẢ các tình huống. Một số người không quan tâm đến tính di động. Một số người không cần phải lo lắng về bảo mật DB. Một số người không cần phải lo lắng về khả năng mở rộng của DB.

Theo ý kiến ​​của tôi, bạn không nên tự động hiển thị cơ sở dữ liệu của mình như một dịch vụ web. Nếu hóa ra bạn cần một dịch vụ để hiển thị dữ liệu của mình, thì hãy viết một dịch vụ, nhưng không phải tất cả việc truy cập cơ sở dữ liệu đều phải được thực hiện thông qua các dịch vụ web.

1. Không có lý do gì khiến kết nối cơ sở dữ liệu không được bảo mật
2. Bạn có thể đóng gói cơ sở dữ liệu trong một lớp truy cập dữ liệu (có thể là Khung thực thể)
3. Các dịch vụ web không dễ sử dụng hơn một lớp truy cập dữ liệu được viết tốt.

• Dịch vụ Web tạo thành một API, xác định các tương tác được phép giữa các hệ thống bên ngoài và dữ liệu của ứng dụng.
• Dịch vụ Web tách cơ sở dữ liệu khỏi các tương tác bên ngoài và cho phép lớp dữ liệu được quản lý độc lập khỏi những ảnh hưởng bên ngoài.
• Chỉ cho phép truy cập bởi Dịch vụ Web đảm bảo rằng logic của ứng dụng có cơ hội thực thi, bảo vệ tính toàn vẹn của dữ liệu.
• Dịch vụ Web cho phép thực hiện các biện pháp xác thực / ủy quyền thích hợp nhất, trái ngược với cơ sở dữ liệu yêu cầu tên người dùng và mật khẩu / đặc quyền cấp bảng.
• Dịch vụ Web tạo cơ hội cho việc sử dụng cấu hình và khám phá dịch vụ tự động.
• Lưu lượng của Dịch vụ Web có thể được mã hóa để truyền qua các mạng không an toàn. Không biết bất kỳ giải pháp kết nối DB trực tiếp nào cho phép điều đó ...?

Hầu hết các điểm này dành cho bất kỳ API chính thức nào, không cụ thể là Dịch vụ Web.

Viết một dịch vụ web chỉ đơn giản kết thúc các cuộc gọi đến các thủ tục được lưu trữ dường như là một cách tiếp cận sai lầm để thiết kế một DAL tốt. Nhiều khả năng, các thủ tục được lưu trữ của bạn là mã kế thừa còn sót lại từ hệ thống máy khách-máy chủ cũ hơn, tức là các quy tắc nghiệp vụ được chôn trong SP. Nếu đúng như vậy, bạn thực sự đang cố gắng tạo ra một chiếc ví bằng lụa từ tai một con lợn nái.

Hơn nữa, việc bạn thêm một lớp giao thức tin nhắn SOAP giúp tăng hiệu suất cho các ứng dụng web đã bị 'ép buộc' phải hẹn hò với 'con lợn' này. Tôi đang làm một dự án ngay bây giờ mà ứng dụng MVC-4 mới của chúng tôi đã được hướng dẫn sử dụng một DAL như vậy. Chúng tôi có gánh nặng phải thay đổi cả chữ ký WebMethod và chữ ký SP bất cứ khi nào một câu chuyện người dùng mới xuất hiện yêu cầu những thay đổi đó; mà đối với chúng tôi, là mỗi lần chạy nước rút. Vốn có trong cách tiếp cận passthru như vậy là hai tầng kết hợp chặt chẽ.

1) Việc duy trì cơ sở dữ liệu được giảm thiểu từ phía các nhà phát triển để họ chỉ có thể tập trung vào việc phát triển.

2) Dịch vụ web hỗ trợ giao tiếp giữa các nền tảng khác nhau (hệ điều hành như windows, ios, android, v.v.) một cách rất dễ dàng và hiệu quả. Ví dụ: hãy xem xét một tình huống khi ứng dụng android & ứng dụng ios muốn giao tiếp với một trang web dựa trên java để giao tiếp cả ba thứ, webservice là giải pháp tốt nhất thay vì duy trì ba cơ sở dữ liệu khác nhau.

Nói chung

1. Cấp độ Dịch vụ Web thúc đẩy việc sử dụng lại các yêu cầu dữ liệu chung cho nhiều ứng dụng
2. Dịch vụ Web có thể được thiết lập với tính năng quản lý phiên bản giúp làm lệch nhiều vấn đề phát sinh từ việc phát triển mức ứng dụng. Ví dụ: nếu tôi mới tham gia một dự án, ứng dụng hiện có mà tôi sử dụng làm mô hình tốt để định cấu hình ứng dụng của mình để sử dụng các nguồn cơ sở dữ liệu hiện có.
3. Dịch vụ Web đã phát triển để cho phép các tùy chọn linh hoạt để gửi yêu cầu và nhận lại kết quả phản hồi ở một định dạng chung như JSON bằng cách sử dụng một URI đơn giản, có nghĩa là các ứng dụng khách có thể được phát triển bằng một tiêu chuẩn chung hơn khuyến khích các giao diện thống nhất đáng tin cậy.

Tôi mới bắt đầu làm quen với ASP.NET Web Api và dự định tạo dịch vụ dữ liệu trước.

Gần đây tôi đã tập trung vào các ứng dụng web .NET MVC với việc sử dụng khung thực thể.

1. Nếu bạn đã sử dụng MVC, Web Api cũng sử dụng MVC với bộ điều khiển Api vì vậy đường cong học tập để xây dựng các dịch vụ khá dễ dàng.

Gần đây tôi thấy mình đang rơi vào tình trạng khó chịu với ứng dụng web MVC mà tôi đang xây dựng ban đầu dựa trên các quy trình được lưu trữ của Oracle. Phiên bản gốc là Oracle 9 hoặc thậm chí trước đó đã đưa ra một vấn đề khác với Visual Studio 2012 khi thúc đẩy cách tiếp cận nhà máy kết nối hiện đại hơn với các cụm thời gian tải tìm kiếm các tệp dll phù hợp để sử dụng dựa trên các kết nối cấu hình web và tên TNS.

Không thể kết nối với cơ sở dữ liệu với thông báo lỗi 'không còn được hỗ trợ'. Vì tò mò, tôi đã tải xuống Oracle 12c và tạo một số kết nối cấp ứng dụng hoạt động tốt với tên TNS của tôi và dll lắp ráp tải và tôi có thể làm việc với Oracle mà không gặp vấn đề gì.

Có một số dịch vụ web được xây dựng đang hoạt động với các kết nối với phiên bản Oracle cũ hơn. Chúng được xây dựng với các phương pháp được ánh xạ cụ thể đến các bảng đã chọn, tuy nhiên, tôi thất vọng. Tôi sẽ phải viết của riêng tôi.

Tôi được biết rằng nhóm chịu trách nhiệm duy trì cơ sở dữ liệu Oracle rằng họ sẽ viết các thủ tục mới được lưu trữ để thay thế các thủ tục cũ hơn mà tôi đang sử dụng để trừu tượng hóa giao diện máy khách và các lớp logic nghiệp vụ.

Vì vậy, suy nghĩ đầu tiên của tôi là tất cả các yêu cầu dữ liệu phổ biến như điền vào danh sách thả xuống hoặc tự động hoàn thành với dữ liệu toàn doanh nghiệp đều được thực hiện thông qua các dịch vụ dữ liệu gọi là thủ tục lưu trữ Oracle. Tại sao phải lặp lại quy trình đó trên từng ứng dụng và từng nhà phát triển phải vật lộn với các vấn đề về cấu hình và phiên bản / tải lắp ráp, TNS?

vì thế....

1. Đối với nhiều sự cố máy chủ cơ sở dữ liệu, chẳng hạn như sử dụng các thủ tục được lưu trữ của Oracle trong ứng dụng .NET MVC thường có thể đang sử dụng EF cho việc sử dụng dữ liệu SQL Server, tại sao không đẩy những vấn đề đau đầu đó lên các phương pháp dịch vụ Web Api nơi các vấn đề cấu hình đó có thể được tách biệt.
2. Một lần nữa, giao diện máy khách có thể được thực hiện bằng JavaScript, JQuery và JSON mà bạn đang sử dụng nếu bạn đang thực hiện việc này bằng cách sử dụng Web Api để thực hiện các yêu cầu dữ liệu SQL Server.

Tôi là Nhà phát triển / Nhà phân tích ứng dụng chứ không phải DBA vì vậy quan điểm của tôi là một trải nghiệm với sự thất vọng không bao giờ dứt khi phải liên tục sửa đổi các ứng dụng khi các công cụ cơ sở dữ liệu phát triển.