Tại sao phải sử dụng dịch vụ web thay vì truy cập trực tiếp vào cơ sở dữ liệu quan hệ cho ứng dụng Android?

Tôi đã tìm kiếm trên web cách truy cập một cách hiệu quả vào cơ sở dữ liệu trung tâm ở một địa điểm từ xa và tôi đã gặp các đề xuất sử dụng các dịch vụ web thay vì truy cập trực tiếp (ví dụ JDBC, v.v.) vào cơ sở dữ liệu. Tôi tự hỏi lý do của điều đó và bất kỳ đề xuất nào khác .

Thêm một lớp dịch vụ web cung cấp cho bạn một cơ hội để làm cho máy khách của bạn nhẹ hơn, cả về sức mạnh CPU cần thiết và băng thông được sử dụng trong quá trình xử lý. Cả hai yếu tố đều cực kỳ quan trọng đối với người dùng cuối:

• Sử dụng ít CPU làm tăng tuổi thọ pin,
• Sử dụng ít băng thông hơn giúp giảm thanh toán hàng tháng cho người dùng có gói đồng hồ đo

Bằng cách giới thiệu một lớp ứng dụng web, bạn chuyển phần lớn quá trình xử lý từ máy khách di động cầm tay thấp, băng thông thấp, bộ nhớ thấp sang máy chủ có băng thông cao, có công suất cao, có nhiều bộ nhớ hơn nhu cầu - một môi trường nơi xử lý và truyền thông tốn một phần chi phí mà họ phải trả cho khách hàng.

Nhưng chờ đã, có một thứ gì đó dành cho bạn: bằng cách chia nhỏ hệ thống, bạn sẽ kiểm soát nhiều hơn các quy tắc kinh doanh, cấu trúc cơ sở dữ liệu của bạn và các phiên bản của những gì hiện có. Khi bạn để máy khách di động kết nối trực tiếp với cơ sở dữ liệu, thiết kế của bạn sẽ "kết hôn" với cấu trúc cơ sở dữ liệu đó: gần như mọi thay đổi sẽ phá vỡ khả năng tương thích ngược với máy khách có thể miễn cưỡng nâng cấp ứng dụng của mình.

Ngược lại, việc thêm một dịch vụ web ở giữa cho phép bạn phát triển giao diện cho các máy khách di động theo những cách dễ quản lý hơn: ví dụ: bạn có thể giữ giao diện cũ, thêm một giao diện mới hoạt động "song song" với nó, và sau đó hoàn toàn cơ cấu lại cơ sở dữ liệu của bạn mà không phá vỡ một khách hàng.

Nếu bạn tuân theo một số nguyên tắc thiết kế cơ bản trong khi thiết kế dịch vụ web của mình, bạn cũng có thể nhận được những lợi ích đáng kể bằng cách sử dụng lại cơ sở hạ tầng phía máy chủ trưởng thành đã được áp dụng: ví dụ: bạn có thể nhận được các dịch vụ bộ nhớ cache và proxy miễn phí.

Cuối cùng, điều này sẽ mở ra cơ hội cho các nhà phát triển khác đưa ứng dụng của bạn đến các nền tảng mà bạn không thể tự phục vụ, cuối cùng là phát huy lợi thế của công ty bạn.

Nó đặt một lớp trừu tượng giữa ứng dụng và DB. Điều này mang lại cho bạn rất nhiều lợi thế như:

• Giới hạn quyền truy cập vào DB chỉ ở những phần mà ứng dụng cần. Điều này vừa đơn giản hóa mã của ứng dụng, vừa giữ DB của bạn an toàn.
• Làm cơ sở cho hoạt động bên trong của DB, vì vậy nếu sau này bạn quyết định thay đổi lược đồ, truy vấn hoặc thậm chí toàn bộ cơ sở dữ liệu của bạn, liên kết đến ứng dụng của bạn sẽ không bị hỏng miễn là bạn duy trì lớp giữa chính xác.
• Nó cho phép bạn thêm chức năng ngoài phạm vi của DB. Bộ nhớ đệm dữ liệu khá ổn định chẳng hạn. Các quy tắc kinh doanh là một phần khác nên tách khỏi DB.

Một lý do khác để không lộ DB trực tiếp - vận chuyển. Hầu hết các cơ sở dữ liệu quan hệ, những thứ mà một người nói chuyện với JDBC, không được thiết kế cho internet công cộng nói chung. Internet không dây là một kết thúc không đáng tin cậy khủng khiếp của internet công cộng nói. Xử lý ngoại lệ sẽ là ác mộng và cuối cùng bạn có thể viết ngược lại lớp dịch vụ web bên trong ứng dụng của mình để tránh mất giao dịch.

Có một số loại cơ sở dữ liệu mới hơn có thể nói HTTP và có thể phù hợp với loại điều này. Họ cũng có xu hướng làm nổi bật các cách để đưa mã ứng dụng sắp xếp vào cơ sở dữ liệu. Bạn có thể muốn xem CouchDb hoặc RavenDb - cả hai đều là dbs tài liệu với khả năng ánh xạ / giảm hoạt động trên json và http, giống như nhiều dịch vụ web hiện đại.