API REST có thể được sử dụng làm lớp nghiệp vụ không?


9

Tôi đang sử dụng mẫu thiết kế PHP Codeigniter MVC

và tôi đã có dự án này với một số loại quy trình kinh doanh cụ thể

Trong ứng dụng của mình, tôi sẽ xử lý 2 API REST hiện có:

  1. Google
  2. Trello

Tôi đã nảy ra ý tưởng tạo API REST để hoạt động như Lớp logic nghiệp vụ (BBL)

đến lượt nó truy cập trực tiếp vào các mô hình của tôi để lấy dữ liệu cần thiết để hình thành các quy tắc kinh doanh

và bộ điều khiển giao tiếp với BLL với máy khách REST, nhập mô tả hình ảnh ở đây

Đó có phải là cách tiếp cận tồi cho hiệu suất?

Có tốt hơn không khi tạo 2 lớp Mô hình một là Lớp truy cập dữ liệu (DAL) và một lớp là Lớp logic nghiệp vụ (BLL)


REST được sử dụng cho các tương tác giữa các thành phần. Nó không phải là một lớp kiến ​​trúc! Tuy nhiên, nó có thể được sử dụng trong một kiến ​​trúc lớp.
Dave Hillier

Các ngữ nghĩa của câu hỏi là sai. Nó không thể được sử dụng như một lớp kiến ​​trúc, nhưng nó có thể được sử dụng như một giao diện cho một lớp.
Dave Hillier

Câu trả lời:


11

Vấn đề tôi thấy với cách tiếp cận của bạn là bạn đang xây dựng API REST cho chỉ một người tiêu dùng, bộ điều khiển của bạn và điều đó quá mức cần thiết. Đừng chỉ thêm một lớp chỉ để truyền dữ liệu từ lớp này sang lớp khác, không có lý do gì, bạn sẽ tự tạo công việc cho mình mà không có thêm lợi ích.

Một cách (nhanh chóng) để làm cho API của bạn trở nên hữu ích nếu đó là điểm cuối duy nhất mà bộ điều khiển của bạn (tức là ứng dụng của bạn) cần. Xem xét điều này:

nhập mô tả hình ảnh ở đây

Đột nhiên API REST của bạn có mục đích và đó là cung cấp giao diện hợp nhất cho các nhà cung cấp dữ liệu khác nhau của bạn. Ứng dụng của bạn không cần biết về Google hoặc API Trello hoặc bất kỳ nhà cung cấp dữ liệu nào khác mà bạn có thể sử dụng trong tương lai, nó chỉ cần biết về API REST của bạn.

Thiết kế này, mặc dù hữu ích hơn một chút, vẫn còn quá mức nếu ứng dụng của bạn là người tiêu dùng duy nhất. Toàn bộ quan điểm của việc xây dựng API REST là hiển thị giao diện có sẵn công khai để các ứng dụng của bạn chia sẻ. Và chìa khóa ở đây là phơi sáng, API REST của bạn sẽ có sẵn cho mọi người và do đó nó phải được bảo mật. Xác thực và ủy quyền API không phải là nhiệm vụ đơn giản, nếu chỉ có một ứng dụng sử dụng API của bạn, tại sao phải trải qua tất cả các rắc rối? Trừ khi bạn muốn thử nghiệm và học hỏi. Nếu đó là trường hợp, bằng mọi cách đi cho nó.

Trong mọi trường hợp, hiệu suất không phải là một vấn đề. Bạn sẽ thêm một lớp bổ sung, vì vậy rõ ràng sẽ có một số chi phí, nhưng liệu chi phí đó có đáng kể hay không hoàn toàn phụ thuộc vào việc triển khai của bạn. Nếu API REST của bạn là điểm cuối duy nhất, thì có lẽ đó cũng là một ý tưởng tốt để trở thành nơi lưu trữ bộ đệm. Và không chỉ bộ nhớ đệm phía máy chủ, API REST giúp bộ nhớ đệm trình duyệt dễ khai thác hơn một chút và nếu bạn hiểu đúng, hiệu suất tổng thể của ứng dụng của bạn có thể tăng lên, so với cách tiếp cận không phải REST.

tl; dr: Đừng xây dựng những thứ không có mục đích thực sự (trừ khi bạn đang học).


Cảm ơn bạn @Yannis Rizos vì câu trả lời của bạn Tôi thích kiến ​​trúc của bạn và tôi nghĩ tôi sẽ tham gia nhưng một câu hỏi nhỏ, ý nghĩa của "Ứng dụng" là toàn bộ MVC hoặc chỉ có VC (Xem và kiểm soát), vì tôi nghĩ các bộ điều khiển sẽ có rất nhiều cách xử lý mã như xác thực, XHR ... vv tôi không muốn giết nó bằng các lệnh gọi REST ngay cả khi đó sẽ là một vài trong số họ và phần còn lại của BLL sẽ lo phần còn lại
Ahmed Samy

và có tốt không khi kết nối một Api REST khác từ API REST của tôi?
Ahmed Samy

1
@AhmedSamy API REST của bạn về cơ bản là một ứng dụng khác nhau, nó có thể lấy dữ liệu từ bất cứ nơi nào nó muốn, bao gồm các mô hình của bạn và các API khác. Bạn sẽ cần xây dựng bộ điều khiển RESTful cho nó và thậm chí có thể xem. Ứng dụng chính của bạn có thể gọi API REST của bạn thông qua các bộ điều khiển hoặc thông qua các khung nhìn của nó (thông qua Javascript).
yannis

1

Dựa trên bản vẽ của bạn, có vẻ như cần có một mô hình được gọi bởi bộ điều khiển của bạn liên quan đến việc nói chuyện với Google, lấy lại kết quả, định dạng cho ứng dụng của bạn và sau đó gửi đến bộ điều khiển sẵn sàng để đi. Nói cách khác, tất cả các chi tiết cụ thể của google sẽ có trong mô hình đó. tương tự cho trello. Bằng cách đó, nếu bạn cần thêm nhiều apis để tiêu thụ, bạn đã giữ mọi thứ tốt đẹp và riêng biệt.

đây là một chi tiết nhỏ - nhưng hãy nhớ trong thiết kế ứng dụng tổng thể của bạn - bạn phải tính đến sự chậm trễ có thể xảy ra trong việc gửi / nhận thông tin từ máy chủ api đến máy chủ của bạn. nói cách khác, đảm bảo ứng dụng của bạn không bị treo hoàn toàn nếu máy chủ trello bị chậm hoặc ngừng hoạt động.

Apis phải quan tâm đến an ninh nhưng họ không nhất thiết phải là 'công khai'. nhiều apis là kinh doanh để kinh doanh không có gì công khai.

Tôi đã đọc hầu hết cuốn sách này - bản phát hành ngắn, vẫn còn sớm và không đủ - nhưng hiện tại, tất cả đều là php và tác giả đang tích cực tạo và dạy về apis. http://shop.oreilly.com/product/0636920028291.do

tác giả có bài viết liên quan đến api còn lại trên blog của cô ấy. http://www.lornajane.net/blog

và chắc chắn và đọc các bình luận cho bài viết api! nghiêm túc nó sẽ cung cấp cho bạn quan điểm rất có giá trị.

Đề nghị bạn google "hypermedia" và api. bạn có thể không muốn sử dụng nó, nhưng nó sẽ cho bạn thấy một số kỹ thuật khác để tạo api.

Tôi mới tham gia lập trình viên - tôi sẽ nêu lên câu hỏi này nếu có thể! hầu hết các doanh nghiệp sẽ không thể tạo các ứng dụng hoàn toàn mới để tiêu thụ hoặc xuất bản apis. Vì vậy, đưa ra các thực tiễn tốt nhất để tích hợp apis vào các khung mvc hiện có - điều này thực sự quan trọng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.