Liệu logic kinh doanh có thực sự thuộc về máy chủ?


10

Một ngăn xếp điển hình cho ứng dụng web là cơ sở dữ liệu, máy chủ có mã phía máy chủ và người dùng có trình duyệt có HTML / CSS / JavaScript.

Trước khi mở rộng AJAX, MVC, trong đó bộ điều khiển là mã phía máy chủ được xử lý. Một máy chủ phải định tuyến các yêu cầu trả lời cho các trang web động (tức là các giải pháp html được tạo khuôn mẫu như JSP và ASP). Máy chủ để phối hợp các cuộc gọi đến cơ sở dữ liệu và quyết định sử dụng trang động nào để trả lời yêu cầu trang. Kết quả của tất cả những điều này là máy chủ đã kết thúc chứa logic kinh doanh, mặc dù logic kinh doanh không bị ràng buộc chặt chẽ với ý tưởng phục vụ các trang.

Bây giờ chúng tôi đang chuyển sang "Web 2.0" một máy chủ các trang tĩnh sử dụng JavaScript để tự điền và thay đổi những gì họ đang trình bày. Có thể có trong JavaScript. JavaScript thường triển khai một dịch vụ RESTful có nghĩa là nó đang chỉ định truy vấn cơ sở dữ liệu.

Vì vậy, máy chủ được để lại vai trò phục vụ các tệp thực tế và trả lời các cuộc gọi AJAX. Và trả lời các cuộc gọi AJAX chỉ đơn thuần là quản lý phiên và cung cấp bảo mật. Và thực sự, những gì người dùng thậm chí có thể nhìn thấy là dữ liệu cần được chỉ định trong cơ sở dữ liệu.

Vì vậy, từ đó, máy chủ có nên được chuyển sang vai trò của một trung gian ngu ngốc mà đôi khi chỉ làm một cái gì đó như gửi email hoặc loại bỏ một dịch vụ web? Tất cả logic kinh doanh có thể sống trong JavaScript (khi nó không bí mật) hoặc sống trong các thủ tục được lưu trữ khi có?

Nó sẽ có ý nghĩa khi thậm chí có thể kết hợp các máy chủ và cơ sở dữ liệu hoặc làm cho các giải pháp ERP như SAP hoạt động như các máy chủ?

Câu trả lời:


14

Logic nghiệp vụ hầu như luôn phải chạy trên máy chủ mà bạn kiểm soát, vì lý do bảo mật. Nếu theo "máy chủ", bạn có nghĩa là "máy chủ web", thì tôi đồng ý, nó không cần phải có bất kỳ logic kinh doanh nào. Nhưng hầu như bạn luôn cần một máy chủ ứng dụng với logic nghiệp vụ, cho dù đó là bên trong cơ sở dữ liệu hay máy chủ web hay được tách biệt và được gọi bởi máy chủ web.

Có những ứng dụng trong thế giới thực mà máy chủ web không làm gì ngoài việc hiển thị API của máy chủ ứng dụng thông qua các dịch vụ web hoặc JSON.

Ngay cả trước khi có Web 2.0 và AJAX, nó thực sự không được coi là cách tốt nhất để trộn logic kinh doanh của bạn với các trang ASP. Nó được coi là tốt hơn để có logic kinh doanh độc lập và để phần máy chủ của logic trình bày phải ở dạng ASP, JSP hoặc bất cứ thứ gì. Vì vậy, thay đổi thực sự từ web 2.0 là lớp trình bày có thể hoàn toàn bằng javascript. Cá nhân tôi thích điều đó


Vâng, vâng, tôi đồng ý logic kinh doanh không nên có trong một ASP. Đó là điểm của MVC.
Joe

Câu trả lời này là từ gần hai năm trước, và bây giờ những thứ như SproutCore đều là những cơn thịnh nộ. Trên trang web của SproutCore, họ tuyên bố rõ ràng mục tiêu là chuyển logic kinh doanh sang trình duyệt (xem: spoutcore.com/about ). Vậy ... trạng thái của web đã thay đổi chưa? Là logic kinh doanh trên máy khách (đặc biệt là thông qua trình duyệt trong trình duyệt) có ổn hay thậm chí có thể tốt hơn không?
JoeCool

@JoeCool SproutCore đã tồn tại sau đó. Và các cân nhắc về bảo mật của việc đưa logic kinh doanh vào máy khách không thay đổi. Nhưng không phải tất cả các ứng dụng có rất nhiều mối quan tâm bảo mật. Ngoài ra, "tất cả các cơn thịnh nộ" dường như quá cường điệu đối với SproutCore. Nhưng tính khả thi của việc làm nhiều hơn trên máy khách đã tiếp tục tăng - ngoại trừ thiết bị di động đã tiếp tục đạt được sự nổi bật và chúng vẫn thách thức hiệu năng khôn ngoan cho nhiều ứng dụng.
psr

@psr Cấp - nhưng dường như bạn hoàn toàn gạt bỏ việc sử dụng logic kinh doanh trong máy khách, trong khi thực tế, ít nhất một vài công nghệ phổ biến hiện nay đang đi theo hướng rõ ràng.
JoeCool

6

JavaScript thường triển khai một dịch vụ RESTful có nghĩa là nó đang chỉ định truy vấn cơ sở dữ liệu.

Đây là nơi bạn đã nhận sai. REST không phải là CRUD.

Các tài nguyên được hiển thị bởi REST không phải là bản ghi cơ sở dữ liệu của bạn; chúng được quản lý hoàn toàn các đối tượng hoạt động theo logic kinh doanh của bạn. Khi máy chủ nhận được POST hoặc PUT, nó không nên xác nhận và lưu trữ. Nó phải thực hiện bất cứ điều gì phù hợp cho ứng dụng.

Ví dụ đơn giản: một ứng dụng giống như twitter nhận được tweet dưới dạng tin nhắn POST trên một thùng chứa nhất định. Sau đó, máy chủ sẽ phân tích bối cảnh ("bạn là ai?", "Đây là kênh nào?") Và nội dung ("bất kỳ hashtags nào?", Chỉ mục văn bản, v.v.) và lưu trữ tất cả điều này trong hàng đợi tương ứng. Có lẽ thêm một tài liệu tham khảo trực tiếp cho tất cả những người theo dõi của bạn.

Đó là rất nhiều công việc ngoài việc đơn giản là thêm tài nguyên vào container, tất cả đều được xác định bởi logic kinh doanh của bạn. Và nó thuộc về máy chủ.


2

Mối quan tâm của tôi với phương pháp này có thể là do sự hiểu lầm về thiết kế của bạn, vì vậy xin vui lòng bắn hạ tôi.

tuy nhiên, hãy suy nghĩ về khả năng mở rộng, bảo trì và bảo mật của sản phẩm.

Nếu sản phẩm của bạn phát triển ồ ạt, cơ sở dữ liệu sẽ trở thành nút cổ chai, do đó, trong khi "hiệu suất" đề nghị đưa logic nghiệp vụ vào các quy trình được lưu trữ, nó sẽ tải thêm CPU vào máy chủ cơ sở dữ liệu của bạn, đưa ra ngày khi máy chủ đạt công suất tối đa. Không giống như máy chủ web, cơ sở dữ liệu ACID không dễ dàng mở rộng quy mô bằng cách sử dụng phần cứng song song. Nếu sản phẩm của bạn sẽ không bao giờ thành công như vậy, thì đây không phải là vấn đề.

Ý nghĩ về việc duy trì logic kinh doanh trong javascript chạy trên webbrowswers, nơi các trình duyệt khác nhau sẽ yêu cầu các javascriopt khác nhau, nhiều phiên bản trình duyệt, v.v ... Tại sao vấn đề này phức tạp hơn nó?

Như Javiar đã nói, sử dụng cách tiếp cận REST làm API cơ sở dữ liệu cho sản phẩm của bạn thực sự không hợp lý. Lợi ích của giao diện REST là người khác sẽ nghĩ ra các cách khác nhau để sử dụng và truy vấn giao diện REST của bạn. Tuy nhiên đây là tài nguyên logic kinh doanh bài công khai và không phải tài nguyên bản ghi bảng cấp thấp. Ý nghĩ làm cho các truy vấn dữ liệu cấp thấp như vậy có sẵn trên api HTTP nghe có vẻ như một cơn ác mộng bảo mật.


+1, để mua chuộc vấn đề tương thích trình duyệt. Ngoài ra, viết mã doanh nghiệp bằng JavaScript đòi hỏi một kỹ năng bổ sung và không cho phép bạn sử dụng các phương thức trong các lớp nghiệp vụ của mình.
NoChance

2

Mặc dù có nhiều trường phái suy nghĩ về điều này, và chắc chắn không có cách nào có thể được gọi là "cách đúng" trên toàn cầu, trong khi tất cả những cách khác là "sai cách" trên toàn cầu, có một số lý do để cô lập logic kinh doanh ở phía máy chủ và truy cập các đối tượng và dịch vụ đó thông qua dịch vụ RESTful.

Câu trả lời ngắn gọn là chủ yếu là về quản lý rủi ro, giám sát và cải thiện hiệu suất.

Chi tiết:

Lý do tối quan trọng số 1 là bảo mật. Khách hàng không bao giờ được tin tưởng để gửi bất cứ thứ gì ngoài rác vào máy chủ và bằng cách giữ phía máy chủ khía cạnh bảo mật, bạn cách ly nguy cơ tiềm ẩn của người dùng lừa đảo làm hỏng hệ thống của bạn. Hãy nhớ rằng, Javascript hoàn toàn là phía máy khách và có thể thay đổi một cách tầm thường, vì vậy bạn KHÔNG THỂ TIN TƯỞNG.

Lý do số 2 là tách mối quan tâm. Lập trình viên javascript của bạn có thể không phải là một chuyên gia về bảo mật và chuyên gia bảo mật của bạn có thể không giỏi về Javascript. Bằng cách tách logic nghiệp vụ khỏi logic trình bày, bạn tránh vượt qua những lo ngại này, vì javascript sẽ không được phép truy cập các tài nguyên vượt quá mức cho phép của nó và bị đưa ra lỗi, việc xử lý nằm trong ưu tiên của Trình lập trình tập lệnh. Tương tự, anh chàng Bảo mật sẽ không gỡ lỗi Javascript để xem cách bảo mật được duy trì.

Lý do số 3 là hiệu suất. Logic kinh doanh có khả năng có thể đòi hỏi tài nguyên máy chủ và cơ sở dữ liệu. Bằng cách giữ logic đó tách biệt khỏi các thành phần UI của bạn, sau đó bạn có thể mở rộng chỉ phần đó của ứng dụng, giúp việc giải quyết các tắc nghẽn trở nên dễ dàng hơn nhiều. Ngoài ra, việc cách ly quy trình kinh doanh nào đang tải hệ thống hoặc cơ sở dữ liệu của bạn dễ dàng hơn nhiều nếu quy trình kinh doanh được thực thi trên máy chủ.

Một hệ quả ở đây là thường một số quy trình kinh doanh sẽ sử dụng cùng một dữ liệu và do đó bạn có thể triển khai bộ đệm ẩn ở phía máy chủ để giảm tải toàn bộ hệ thống mà có thể không thể / bảo mật để cấp cho khách hàng quyền truy cập vào mã.

Cuối cùng, tôi sẽ đề xuất rằng để duy trì các tiêu chuẩn ACID, Business Logic thực sự cần phải có trên máy chủ. Tôi nhớ duy trì một sản phẩm thanh toán chạy trong trình duyệt web, chỉ có kết nối cơ sở dữ liệu với máy chủ. Nếu thanh toán hàng ngày (có thể mất một giờ hoặc nhiều hơn vào một ngày tốt!) Bị gián đoạn, giả sử, do trình duyệt bị đóng hoặc bị sập, có thể mất vài giờ để loại bỏ mớ hỗn độn mà cơ sở dữ liệu còn sót lại trong trạng thái không nhất quán Hãy nhớ rằng, điều này cũng liên quan đến thẻ tín dụng, vì vậy hồ sơ thanh toán cũng phải được kiểm tra đối với bộ xử lý!

Logic nghiệp vụ phía máy chủ chủ yếu là tầm thường để đảm bảo cập nhật ACID, vì có bất kỳ khuôn khổ nào cho bất kỳ ngôn ngữ nào để duy trì giao dịch, ở cấp độ ứng dụng hoặc cơ sở dữ liệu. Nếu bạn đang thực hiện việc này thông qua nhiều bản cập nhật từ một ứng dụng web ... bạn sẽ có trạng thái không nhất quán tại một số điểm và có khả năng nó sẽ ảnh hưởng đến ứng dụng của bạn.

Mặc dù có thể rất hấp dẫn khi nghĩ về các dịch vụ RESTful chỉ đơn giản là một cách để truy cập cơ sở dữ liệu, bạn không nên rơi vào cái bẫy này, vì đó là một công thức tốt cho thảm họa. Mô hình đối tượng bạn trưng ra thông qua dịch vụ RESTful có thể liên quan đến cơ sở dữ liệu của bạn, nhưng thực sự nên gói gọn logic kinh doanh của bạn thay vì chỉ sử dụng nó làm công cụ CRUD.


+1 để nâng cao nhiều điểm tốt. Hệ thống thanh toán bạn sử dụng làm ví dụ có thiết kế kỳ lạ nhất tôi từng nghe nói.
NoChance

Nó có cái tên kỳ lạ nhất mà tôi từng nghe đến, mặc dù tôi vẫn thấy các tài liệu tham khảo về nó treo xung quanh. Nó được gọi là HURLnet ISP Admin, và khá là cần thiết để duy trì. Chúng tôi đã có giấy phép mã nguồn đầy đủ và tôi đã sử dụng rộng rãi khi họ ngừng hỗ trợ.
SplinterReality
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.