API REST so với các cuộc gọi DB trực tiếp trong Ứng dụng máy tính để bàn

Tôi hiện đang lên kế hoạch cho một ứng dụng sẽ được sử dụng trong một công ty. Nó là cần thiết để xây dựng một ứng dụng máy tính để bàn. Hiện tại họ không chắc chắn ứng dụng sẽ có sẵn trên thiết bị di động hay trình duyệt trong tương lai gần.

Tôi có hai khả năng:

Truy cập cơ sở dữ liệu trực tiếp từ Ứng dụng máy tính để bàn
Tạo API REST và kết nối với cái này

Tôi có thể sử dụng API REST nếu ứng dụng chỉ là Ứng dụng máy tính để bàn trong công ty không? Tôi biết rằng nó có thể, nhưng nó là "đúng"? (Thực hành tốt nhất)

Có một số ưu điểm và nhược điểm (có thể) để tạo trực tiếp API REST:

Nhược điểm:

Mất nhiều thời gian hơn để phát triển
Phức tạp hơn
Máy chủ làm nhiều việc hơn
Vân đê bảo mật
Chậm hơn? (Máy chủ và Ứng dụng Máy tính để bàn nằm trên cùng một Mạng)

Ưu điểm:

Di chuyển sang các nền tảng khác dễ dàng hơn
Logic nghiệp vụ cũng cần thiết khi gọi trực tiếp cơ sở dữ liệu. Sẽ không mất nhiều thời gian để phát triển
Sự phức tạp cũng vậy
Bảo mật (như được đề cập bởi tkausl trong các bình luận)
Khả năng bảo trì (như được đề cập bởi WindRaven trong các bình luận)

— devz
nguồn

Bạn thực sự được coi Security issueslà một bất lợi cho REST-API?

— tkausl

Tôi có thể bảo vệ API của mình với ví dụ OAuth2 và TLS, nhưng điều này sẽ tăng thêm công việc. Tôi không biết cuộc gọi DB trực tiếp an toàn đến mức nào. Ví dụ với JPA. Đó là lý do tại sao tôi đã thêm một dấu hỏi vì tôi không thực sự chắc chắn.

— devz

Chà, bạn không thể nhận được bảo mật ít hơn một cuộc gọi db trực tiếp, trừ khi bạn cho đăng nhập root.

— tkausl

Một ưu điểm khác, Một thay đổi trong logic nghiệp vụ chỉ cần được thực hiện trên API REST và được triển khai đến máy chủ, không được thực hiện và sau đó mọi khách hàng đều cập nhật. (với điều kiện giao diện API không thay đổi do kết quả)

— RubberChickenLeader

Là cơ sở dữ liệu chạy trên cùng một máy tính như ứng dụng? Nếu không, tôi thậm chí sẽ không nghĩ về việc truy cập ghi trực tiếp vào cơ sở dữ liệu.

— CodeInChaos

Câu trả lời:

Khi nói đến một ứng dụng lớn với cơ sở dữ liệu khổng lồ chứa hàng triệu bản ghi, bạn sẽ sớm nhận ra, lựa chọn đơn giản, cập nhật, chèn và xóa đơn giản là không đủ.

Vì vậy, bạn bắt đầu suy nghĩ theo một cách khác. Bạn tạo các thủ tục và trình kích hoạt để xử lý các công cụ phức tạp hơn trực tiếp trong cơ sở dữ liệu và điều này không tốt lắm. Cơ sở dữ liệu cung cấp hiệu suất tuyệt vời khi thực hiện các hoạt động CRUD. Thủ tục lâu? Không nhiều lắm.

Vấn đề với thủ tục

Bây giờ hãy tưởng tượng, bạn chuyển sang một cơ sở dữ liệu không hỗ trợ khái niệm thủ tục? Bạn định làm gì? Thay vào đó, bạn buộc phải chuyển các thủ tục sang cơ sở mã của mình, nơi bạn có thể khá chắc chắn rằng một khi bạn lập trình nó trong Java, nó sẽ luôn ở đó, bất kể bạn chọn công cụ cơ sở dữ liệu nào.

Chưa kể, các thủ tục của bạn thường là một phần của logic kinh doanh của bạn và không nên để logic kinh doanh của bạn được phân bổ trên cơ sở dữ liệu và cơ sở dữ liệu của bạn.

Tốt nhất, bạn nên luôn có một người trung gian giữa cơ sở dữ liệu và khách hàng thực hiện các quy tắc kinh doanh của riêng mình. Cung cấp quyền truy cập trực tiếp vào cơ sở dữ liệu không phải là một ý tưởng hay, bởi vì khi bạn làm như vậy, người có quyền truy cập có quyền truy cập trực tiếp vào các bảng và có thể thực hiện bất kỳ điều gì với dữ liệu có.

Nhược điểm

Mất nhiều thời gian hơn để phát triển: Tất nhiên, bạn đang tạo một hệ thống mới, việc này sẽ tốn nhiều thời gian hơn là chỉ đơn giản là cung cấp cho khách hàng một chuỗi kết nối cơ sở dữ liệu và để anh ta viết các truy vấn.
Phức tạp hơn: Độ phức tạp của một hệ thống> độ phức tạp của truy vấn cơ sở dữ liệu.
Máy chủ làm nhiều việc hơn: Không nhất thiết. Với thiết kế tốt, bộ nhớ đệm, ... bạn có thể di chuyển tải từ máy chủ cơ sở dữ liệu đến một trong các trung gian hòa giải.
Chậm hơn: Về mặt phát triển? Đúng. Về tốc độ khi lấy dữ liệu? Không. Bạn có thể tối ưu hóa trình hòa giải của mình bằng cách sử dụng bộ nhớ cache (chẳng hạn như - phổ biến kể từ tháng 1 năm 2016 - Redis, Elaticsearch) và thực sự làm cho nó cung cấp dữ liệu nhanh hơn truy vấn cơ sở dữ liệu đơn giản.

Ưu điểm

Di chuyển sang các nền tảng khác dễ dàng hơn: Di chuyển sang một công cụ cơ sở dữ liệu mới? Chắc chắn rồi. Di chuyển toàn bộ hòa giải sang một ngôn ngữ mới? Không hẳn vậy.
Logic nghiệp vụ cũng cần thiết khi gọi trực tiếp cơ sở dữ liệu. Sẽ không mất nhiều thời gian để phát triển: Như đã giải thích trước đây, vấn đề thủ tục.
Bảo mật: Với ủy quyền thích hợp, có hòa giải viên chắc chắn an toàn hơn nhiều so với việc cho phép người dùng truy cập trực tiếp vào cơ sở dữ liệu, bởi vì bạn hạn chế anh ta đến các điểm cuối chỉ chạy các truy vấn bạn muốn.
Khả năng bảo trì: Một trong những lợi ích tốt nhất của việc có một hòa giải viên. Nếu có lỗi trong API mà khách hàng của bạn gọi, bạn sửa nó, đẩy bản sửa lỗi đến kho lưu trữ VCS của bạn, xây dựng trình hòa giải của bạn từ phiên bản hiện tại của VCS có chứa bản sửa lỗi và tất cả các máy khách của bạn đột nhiên sử dụng bản sửa lỗi mà không cần chúng phải sửa tải về một bản cập nhật. Điều này chỉ đơn giản là không thể làm được, nếu các truy vấn được lưu trữ trực tiếp trong các ứng dụng khách. Trong trường hợp đó, khách hàng buộc phải cập nhật ứng dụng của họ.

— Andy
nguồn

Bạn có thường xuyên đối mặt với thách thức chuyển sang cơ sở dữ liệu không hỗ trợ khái niệm thủ tục khi bạn thực sự sử dụng chúng không?

— quấy rối

@harasta Hai lần trong 2 năm qua. Khi tôi và nhóm mà tôi đang làm việc trong một dự án quyết định chuyển từ MySQL hoặc PostgreSQL sang MongoDB như một phần để chuyển sang Node.js và cũng để trốn tránh các khóa chết và lưu trữ các đối tượng dưới dạng tổng hợp thay thế.

— Andy

Có một tùy chọn khác ngoài việc truy cập trực tiếp vào db. "API hòa giải" không phải sử dụng HTTP, do đó máy chủ HTTP hoàn toàn không phải tham gia. Nó có thể chỉ là API cấp mã. Một câu hỏi khác là, với điều kiện là bạn không hài lòng với tốc độ ngôn ngữ lập trình của mình, là liệu có API (quyền truy cập REST) được viết bằng một số ngôn ngữ / nền tảng khác ngoài logic kinh doanh của bạn không ...

— forsberg

Đây là ý kiến của tôi về vấn đề này: Bạn có ý tưởng đúng đắn muốn sử dụng dịch vụ web, nhưng bạn có thể đang lên kế hoạch sử dụng sai công nghệ.

Khi bạn nói REST, tôi giả sử bạn đang nói về Asp.Net WebApi. Đó là công nghệ sai cho các ứng dụng mạng nội bộ. REST & WebApi thật tuyệt vời, đừng hiểu sai ý tôi, nhưng đối với bất kỳ loại ứng dụng nội bộ nào, dịch vụ web WCF là cách để đi theo quan điểm khiêm tốn của tôi. Chúng cho phép khách hàng tham chiếu điểm cuối dịch vụ giống như thư viện lớp, điều đó có nghĩa là bạn không giao dịch với XML hoặc JSON trong máy khách để bàn của bạn. Bạn đang làm việc với các lớp và các đối tượng.

Dù sao, vâng. Bạn đã có ý tưởng đúng. Nếu họ không chắc họ có cần máy khách dựa trên web hay không, thì bạn phải kiến trúc hệ thống của bạn để dễ dàng thêm nó nếu họ quyết định họ muốn nó sau này. Việc thêm các loại khách hàng khác nhau sẽ dễ dàng hơn nhiều khi bạn có kiến trúc hướng dịch vụ.

— Vịt cao su
nguồn

Thật là ngu ngốc dễ dàng sử dụng một khách hàng để khử lưu huỳnh json cho các đối tượng. Các lớp thậm chí có thể được tạo tự động từ ví dụ json bằng cách sử dụng json2csharp.com . Nó hoạt động rất tốt với ứng dụng khách http từ gói nuget microsoft.aspnet.webapi.client. Tôi hứa sẽ quay lại vùng đất đối tượng nhanh hơn so với giao dịch với các tham chiếu khách hàng WCF mà tôi hứa, vì vậy đây không phải là trình điều khiển chính để chọn WCF.

— Esben Skov Pedersen

@EsbenSkovPedersen có một sự khác biệt giữa dễ dàng ngu ngốc và tự động .

— RubberDuck

Bởi vì không bao giờ có vấn đề với WCF? Điều đó không thể đúng.

— Esben Skov Pedersen

Ai đã từng nói rằng không có vấn đề gì với WCF @EsbenSkovPedersen? Tôi chắc chắn là không. Mỗi phần của công nghệ có vấn đề của nó. Vấn đề của bạn là gì?

— RubberDuck

Khi bạn nói nó dễ hơn ngu ngốc dễ dàng, bạn ngụ ý rằng. Tôi không có vấn đề gì.

— Esben Skov Pedersen

Nhìn vào nó theo cách này, nó chắc chắn là một mô hình phổ biến và có thể được mô tả một cách hợp lý là thực tiễn tốt nhất.

Tùy thuộc vào nền tảng của bạn, bạn có thể tìm thấy công cụ gần như khiến vấn đề biến mất - Microsoft có hỗ trợ ODATA cho các ứng dụng được kết nối sẽ tạo biểu mẫu qua dữ liệu một cách đơn giản sau khi bạn leo lên đường cong học tập.

Thực tế hơn - xác định API bạn cần cho lớp dữ liệu của mình trong ứng dụng máy tính để bàn và mã cho API đó. Đặt tất cả quyền truy cập cơ sở dữ liệu đằng sau API đó - điều thực sự làm cho mọi thứ tốt hơn từ góc độ phát triển ứng dụng - và sau đó vị trí của mã truy cập cơ sở dữ liệu thực tế trở nên ít quan trọng hơn (cùng một API có thể được triển khai bằng mã nói chuyện trực tiếp với cơ sở dữ liệu hoặc bằng mã nói chuyện gián tiếp với cơ sở dữ liệu thông qua điểm cuối nghỉ). Nếu bạn bắt đầu với việc triển khai trực tiếp thì phiên bản REST về cơ bản sẽ là một trình bao bọc cùng một API để bạn không bị phạt quá nặng ...

Nó có thể không hoàn toàn đơn giản như tôi muốn làm cho nó trở thành - nhưng đó là một mô hình tốt, nó mang lại cho bạn sự linh hoạt mà bạn có thể cần mà không cần đi xa tuyến đường YAGNI .

— Murph
nguồn