2013-01-09 32 views
18

Gần đây, một số đồng nghiệp và tôi đã thảo luận về việc liệu các dịch vụ AngularJS có nên có nhà nước hay không. Chúng tôi đã đưa ra một số lý lẽ cho và chống lại nó và tôi muốn nhận thêm suy nghĩ và phản hồi về chủ đề này. Trong tìm kiếm của tôi, tôi tìm thấy this nhưng dường như không có bất kỳ thực hành tốt nhất rõ ràng nào được đề cập. Trong thế giới phía máy khách không một dịch vụ nào không bao giờ nên giữ trạng thái, nhưng tôi bắt đầu nghĩ rằng nó có thể là phía máy khách được chấp nhận bởi vì nó là một vấn đề khác.Dịch vụ Góc có nên có trạng thái không?

Lý do cho các dịch vụ giữ nhà nước:

  1. Dịch vụ này sẽ không thể được truy cập bởi nhiều chủ đề. Mỗi trình duyệt sẽ có phiên bản dịch vụ riêng của mình.
  2. Cho phép dịch vụ chỉ giữ trạng thái mà nó quan tâm thay vì lưu trữ trong rootScope. đóng gói

Lý do cho các dịch vụ để không giữ trạng thái:

  1. Dịch vụ không còn idempotent. Các chức năng gọi có thể thay đổi trạng thái và do đó có thể có các kết quả khác nhau khi gọi nó dựa trên trạng thái của dịch vụ.
  2. Tôi nghĩ rằng tổng thể điều này sẽ dễ dàng hơn để kiểm tra.

Một cách có thể giải quyết # 2 trong phần "cho dịch vụ giữ trạng thái" sẽ là có đối tượng appState được đặt trên rootScope chứa trạng thái hiện tại của ứng dụng. Sau đó, tất cả các tiểu bang sẽ được thu thập tại một địa điểm và sau đó bạn chỉ cần kéo những gì bạn cần ra khỏi nó trong dịch vụ của bạn. Tôi tìm thấy điều này và tự hỏi

Trả lời

9

Trong AngularJS, dịch vụ are passed in via factory function. Và về cơ bản chúng là các đối tượng có thể chứa một số trạng thái (ví dụ: để lưu bộ nhớ đệm hoặc lưu trữ dữ liệu cần thiết để thực hiện các hành động của chúng).

Một giải pháp tốt có thể khiến cả hai khuyết điểm của việc có/không có trạng thái là khi dịch vụ (có thể thực sự hoạt động) trả về đối tượng chứa trạng thái.

Hãy nhìn vào các dịch vụ $http: bạn có thể nhận thể hiện của dịch vụ này gọi

var x = $http({url:'...'}); 

Và sau đó gọi bởi

var result = x.get() //actually `$http.get` is shortcut of this operation 

Cùng với ngResource: sử dụng dịch vụ bạn nhận được đối tượng với một số nhà nước có thể thực hiện các hành động mong muốn. Vì vậy, về cơ bản tôi nghĩ rằng đó là lựa chọn tốt nhất: từ một điểm bạn tránh 'tác dụng phụ' bằng cách di chuyển trạng thái có thể được sửa đổi bởi hành động thành đối tượng riêng biệt, không được lưu trữ trong bản thân dịch vụ, nhưng có thể có trạng thái cụ thể trong đối tượng đó để có thể lưu trữ thông tin tùy chỉnh (như thông tin auth vv).

+0

Điểm tốt về $ http và $ tài nguyên. Ngoài ra, tôi thích suy nghĩ của bạn về chỉ lưu trữ trạng thái mà sẽ không được sửa đổi bởi các chức năng được gọi trên dịch vụ (ngoại trừ có thể khi khởi tạo dịch vụ). – testing123

13

Điều này có thể phụ thuộc vào ý nghĩa của "trạng thái", nhưng trong nhiều trường hợp, tôi nghĩ câu trả lời là có: các dịch vụ nên giữ trạng thái.

Ví dụ: nếu bạn có dịch vụ chịu trách nhiệm liên lạc với API, dịch vụ đó có thể giữ trạng thái xác thực.

Nhân tiện, tôi không chắc chắn bao nhiêu vấn đề không cần thiết cho các dịch vụ AngularJS - chúng là những người độc thân và do đó vốn có một số trạng thái. Bạn có thể (và trong một số trường hợp phải) tạo ra các phương thức không cần thiết trên dịch vụ, nhưng đó là một vấn đề riêng biệt.

+0

Điểm tốt về việc giữ trạng thái xác thực. Để làm cho idempotent dịch vụ, tôi đã có nghĩa là, như bạn đã đề cập, có phương pháp idempotent. Cảm ơn câu trả lời của bạn. – testing123

+0

Điều tuyệt vời về việc giữ nó trong trạng thái có nghĩa là bạn có thể sử dụng một biến tham chiếu. Và vì lý do đó bạn có thể tạo ra một mô tả rõ ràng về cấu trúc dữ liệu phức tạp! – Exitos

1

IMO có, dịch vụ CÓ thể nêu rõ. Tôi nói "có thể" như một dịch vụ có thể được coi là một cái gì đó giống như một dịch vụ khách hàng không cổ điển - một nhà cung cấp, nhưng nó cũng có thể có nghĩa là một cái gì đó hoàn toàn khác, trong angularJS. Là một phần tử một ví dụ rootScope-y trong ứng dụng, nó có thể được sử dụng chỉ để quản lý nhà nước, ví dụ. Trong trường hợp của tôi, điều đó cho phép tôi đảm bảo cấu trúc trạng thái giống nhau trên nhiều ứng dụng, và mặc dù cấu trúc trạng thái riêng của chúng được xác định cho mỗi cấu trúc khởi động, những thứ như trạng thái phiên luôn giống nhau và được cập nhật khi mô-đun đó được thay đổi.

-4

Lý do dịch vụ không có trạng thái là nó dẫn đến điều kiện chủng tộc khi bạn có nhiều luồng truy cập dịch vụ.

Một vấn đề thường gặp với nhà nước trong một dịch vụ là:

  1. thread 1 ghi vào tình trạng
  2. chủ đề 2 ghi vào tiểu bang
  3. thread 1 lần đọc từ trạng thái
  4. chủ đề 2 lần đọc từ tiểu bang

Chủ đề 1 giờ đây có giá trị sai.

Điều đó đang được nói, javascript hiện là chuỗi duy nhất nên bạn sẽ không gặp vấn đề về truy cập luồng như thế này. Tuy nhiên, tôi sẽ lo lắng nếu tôi có một dịch vụ mà nhiều cuộc gọi http $ không đồng bộ đều được ghi vào cùng một biến dịch vụ. Nếu chỉ vì vậy tôi có thể ngủ ngon hơn vào ban đêm, tôi sẽ cố gắng viết tất cả các phương pháp dịch vụ của mình để họ có thể vượt qua các dữ liệu thực tế.

Thay vào đó, để duy trì trạng thái trong dịch vụ, bạn có thể xem xét đặt trạng thái trong phần phụ trợ càng nhiều càng tốt. Những thứ như "xác thực" hoặc thậm chí chiều rộng và chiều cao có thể được duy trì và truy vấn. Điều này có thể mở ra một số khả năng cho phép người dùng điều hướng khỏi ứng dụng, quay lại và tìm tất cả tùy chọn của họ vẫn thiết lập và đăng nhập. Bạn có thể lưu trữ id phiên trong cookie và lưu tất cả nội dung này trên chương trình phụ trợ.

Nếu bạn đã đi tuyến đường có một đối tượng riêng biệt để lưu trữ trạng thái, bạn có thể $ phát ra nó từ dịch vụ khi một cái gì đó trong trạng thái đã thay đổi: how to emit events from a factory. Điều này sẽ có tác dụng phụ tốt đẹp khi có nhiều dịch vụ có thể sửa đổi trạng thái ứng dụng thống nhất vì trạng thái không được lưu trữ trong bất kỳ dịch vụ nào (hoặc tệ hơn trong nhiều dịch vụ).

+2

Bạn đã tự nói, javascript là đơn luồng, vì vậy không có điều kiện chủng tộc, thậm chí không thông qua webworkers vì các webwork có thể chia sẻ tài liệu tham khảo tới các đối tượng.Bạn đang nói về backend, nhưng các lớp trình bày không có gì để làm với sự kiên trì. – mpm

Các vấn đề liên quan