Chúng ta có nên gọi API Web từ ứng dụng MVC trong cùng một giải pháp không?

Tôi đang làm việc trên một dự án trong MVC có ứng dụng di động nên có một điều rõ ràng là chúng ta phải sử dụng API Web để nó có thể được sử dụng trong ứng dụng di động.

Sau khi tạo API khi chúng tôi bắt đầu phát triển trang Web, chúng tôi bối rối và thảo luận về việc nên sử dụng API hay truy cập trực tiếp vào đối tượng Business. Và chúng tôi đã kết thúc sau khi có ý kiến ​​từ nhà phát triển có kinh nghiệm hơn để sử dụng API Web thay vì sử dụng trực tiếp đối tượng Business.

Tôi đang có sự nhầm lẫn về cấu trúc giải pháp này.

1) Tại sao chúng ta nên sử dụng API Web và thực hiện yêu cầu HTTP (tốn thời gian) để lấy hoặc đặt dữ liệu thay vì đối tượng kinh doanh trực tiếp trong cùng một giải pháp.

2) Sau khi có đối số, họ nói nếu khách hàng muốn lưu trữ API và web trên máy chủ đám mây khác nhau và chỉ áp dụng tỷ lệ trên API hoặc có thể anh ta muốn có url khác nhau để truy cập API và Web (đó là một số logic). Vậy trong trường hợp đó chúng ta có nên gọi API Web từ ứng dụng MVC trong cùng một giải pháp không?

3) Nếu chúng tôi lưu trữ API và Web trên các lưu trữ khác nhau thì điều đó có nghĩa là Web của chúng tôi sẽ sử dụng WebClient và có cuộc gọi HTTP trên mỗi điều hướng. Đúng không?

4) Nếu đối tượng kinh doanh của chúng tôi hình thành cả API và lưu trữ web trên các máy chủ khác nhau thì nếu có gì đó thay đổi trong BL sẽ cần cập nhật bản dựng trên cả hai máy chủ.

5) Hoặc chúng ta chỉ nên tạo một dự án cho API và có thể thêm các chế độ xem hoặc trang html để phát triển giao diện Web để theo cách đó chúng ta có thể gọi API trực tiếp từ ajax.

Theo kiến ​​thức của tôi, số 5 là giải pháp tốt nhất hoặc API chỉ dành cho truy cập của bên thứ 3. Nếu chúng ta có DB, EF, lớp dữ liệu và lớp nghiệp vụ trong cùng một giải pháp thì chúng ta không nên sử dụng API để thực hiện các cuộc gọi HTTP và truy cập trực tiếp vào đối tượng kinh doanh. (sửa tôi nếu tôi sai) Cần có API khi ứng dụng di động hoặc máy tính để bàn hoặc bất kỳ ai muốn truy cập ứng dụng để chúng tôi có thể có cùng một kho lưu trữ và lớp dữ liệu.

Trong kịch bản của tôi, tôi đã tạo API vì chúng tôi cũng có ứng dụng di động và ở phía API dự án, chúng tôi đã gọi lớp doanh nghiệp (dự án riêng) và lớp doanh nghiệp giao tiếp với lớp truy cập dữ liệu (dự án riêng). Vì vậy, câu hỏi của tôi là nếu chúng tôi lưu trữ API và web của chúng tôi đến các máy chủ khác nhau thì việc gọi API là yêu cầu HTTP có thể mất nhiều thời gian hơn thay vì sử dụng phương thức từ lớp doanh nghiệp khi chúng tôi tạo dự án và chúng tôi đã tạo ra lớp doanh nghiệp. Trong bộ điều khiển API, chúng tôi chỉ chuyển đổi doanh nghiệp của chúng tôi sang định dạng json.

Tôi đã tìm kiếm trên internet nhưng không nhận được câu trả lời thuyết phục. Tôi đã tìm thấy một blog http://odetocode.com/bloss/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx thảo luận về cùng một điểm nhưng một lần nữa trong blog đó câu hỏi của tôi là tại sao chúng ta cần xem xét kịch bản # 3?

Cập nhật: Chúng tôi có thể có dự án API và dự án MVC khác nhau và chúng tôi có thể gọi API từ web bằng cách sử dụng jvascript hoặc có thể sử dụng mẫu MVVM.

Câu hỏi tuyệt vời! Tôi luôn tìm cách tốt hơn để cấu trúc các dự án của mình .. Mỗi điểm bạn nêu ra đều có giá trị và đã khám phá nhiều cấu trúc giải pháp khác nhau Tôi phải nói rằng tôi đồng ý phần lớn các ý kiến ​​ở đây: không có giải pháp hoàn hảo. Một vài điều cần tự hỏi khi gặp phải loại vấn đề này: Ứng dụng này phức tạp đến mức nào? Tôi cần tích hợp bao nhiêu hệ thống - hoặc cần bao nhiêu hệ thống để tích hợp với hệ thống này? Tôi dự định làm bao nhiêu thử nghiệm? Có một nhóm thiết kế / UI riêng biệt? Chúng ta sẽ cần phải mở rộng quy mô? Điều gì tạo nên một phiên?

Chúng ta hãy xem xét một vài tình huống và cách sử dụng một kỹ thuật thông minh nhỏ để làm cho mọi thứ thực sự bùng nổ (và một số thủ thuật để làm cho mọi thứ dễ dàng hơn một chút) ..

Lưu trữ cả API và trang web trong cùng một dự án
Trong trường hợp này, bạn có thể có một giải pháp duy nhất với các dự án lớp doanh nghiệp bằng 0 hoặc nhiều hơn và một dự án MVC / WebAPI lai (cũng như các dự án khác - tiện ích, v.v.).

Pro
Mọi thứ đều ở một nơi .. Không cần phải giày-sừng trong tin nhắn phức tạp (HttpClient gọi), bạn có thể đã chia sẻ trạng thái phiên (client và server thông qua các tập tin cookie, InProc / OutOfProc phiên, vv), kết nối tổng hợp, logic chia sẻ, vv Triển khai không thể đơn giản hơn.

Con của
Mọi thứ đều ở một nơi .. Đây có lẽ là cấu trúc nguyên khối nhất có thể. Không có giao diện được xác định rõ ràng giữa các lớp của bạn .. Bạn kết thúc với sự gắn kết cao . Các nhà phát triển lười biếng sẽ tránh các giao diện khi xử lý kiểu kiến ​​trúc này khiến cho việc thử nghiệm trở thành một nỗi đau rất lớn. Mở rộng quy mô / đồng định vị ứng dụng sẽ khó khăn.

Sử dụng
Tôi sẽ sử dụng cấu trúc dự án này cho một ứng dụng một lần, nội bộ hoặc đơn giản. Xây dựng hệ thống nhanh chóng để theo dõi đăng ký trại bóng rổ tại Y địa phương? Đây là kiến ​​trúc của bạn!

WebAPI và trang web trong các dự án khác nhau
Tôi có xu hướng thích trường hợp này .. Bạn có một giải pháp duy nhất với một (hoặc nhiều) dự án MVC và một dự án WebAPI.

Modularization Pro ! Khớp nối lỏng lẻo! Mỗi dự án có thể độc lập, được thử nghiệm riêng biệt và có thể được quản lý khác nhau. Điều này cho phép bạn dễ dàng thực hiện các chiến lược bộ nhớ đệm khác nhau tùy thuộc vào nhu cầu của bạn. Bằng cách giữ các ranh giới vững chắc giữa các hệ thống khác nhau của bạn, bạn có thể dễ dàng thiết lập các hợp đồng cho phép bạn thực thi các mô hình sử dụng cụ thể và cắt giảm ma sát có thể (đọc: ít lỗi hơn với ít cơ hội lạm dụng API hơn). Chia tỷ lệ dễ dàng hơn một chút vì bạn chỉ cần chia tỷ lệ các bit đang thấy tải cao. Việc tích hợp trở nên dễ dàng hơn một chút để xử lý vì bạn sẽ cần phải có ý tưởng về API của bạn sẽ trông như thế nào ngay từ đầu.

Con
Bảo trì khó khăn hơn một chút. Nhiều dự án có nghĩa là bạn sẽ cần chủ sở hữu dự án / tính năng để theo dõi các hợp nhất, hợp đồng (giao diện), triển khai, v.v. Bảo trì mã, nợ kỹ thuật , theo dõi lỗi, quản lý nhà nước - tất cả đều trở thành mối quan tâm vì chúng có thể cần được triển khai khác nhau dựa trên theo nhu cầu của bạn. Những loại ứng dụng này cũng đòi hỏi phải lập kế hoạch và quản lý nhiều nhất khi chúng phát triển.

Công dụng
Xây dựng một ứng dụng có thể có 100 người dùng hôm nay và 100.000 người vào tuần tới / tháng? Ứng dụng có phải gửi thông báo, quản lý quy trình công việc phức tạp và có nhiều giao diện (web + ứng dụng di động + SharePoint) không? Có nhiều thời gian trong tay và thích giải quyết hơn 5000 câu đố vào cuối tuần? Đây là kiến ​​trúc dành cho bạn!

Lời khuyên
Đã nêu ở trên, tôi có thể hiểu làm thế nào dự án tiếp theo của bạn có thể trông hơi nản chí. Đừng lo lắng, đây là một vài thủ thuật tôi đã học được trong nhiều năm qua ..

1. Cố gắng sử dụng các phiên phi trạng thái. Trên các hệ thống nhỏ hơn, điều này có thể có nghĩa là lưu trữ cookie được mã hóa chứa ít nhất id nội bộ của người dùng hiện tại và thời gian chờ. Các hệ thống lớn hơn có thể có nghĩa là lưu trữ cookie được mã hóa với id phiên đơn giản có thể được tìm nạp từ kho dữ liệu (redis, lưu trữ bảng, DHT , v.v.) .. Nếu bạn có thể lưu trữ đủ thông tin để bạn không phải truy cập cơ sở dữ liệu chính trên mỗi yêu cầu sau đó bạn sẽ ở một nơi tốt - nhưng hãy cố gắng giữ cookie dưới 1k.
2. Hãy nhận biết rằng có thể sẽ có nhiều hơn một mô hình. Hãy thử suy nghĩ về các mô hình và dự đoán (các liên kết tôi tìm thấy ở đây là .. không tốt .. nghĩ: mục hàng tồn kho của một người là mục hàng đơn hàng của một người khác - cùng cấu trúc cơ bản, nhưng các chế độ xem khác nhau). Một số dự án có một mô hình khác nhau cho từng ranh giới logic / khái niệm (nghĩa là sử dụng một mô hình cụ thể để bắt đầu với một API cụ thể.
3. API ở mọi nơi! Bất cứ khi nào một đối tượng / lớp / cấu trúc tiết lộ bất kỳ dữ liệu hoặc hành vi nào, bạn đang thiết lập API. Hãy chú ý đến việc các thực thể hoặc phụ thuộc khác sẽ sử dụng API này như thế nào. Hãy suy nghĩ về cách bạn có thể kiểm tra API này. Xem xét những gì có thể nói với API này (các đối tượng khác thông qua mã? Các hệ thống khác thông qua giao thức?) Và cách dữ liệu đó được hiển thị (gõ mạnh? JSON? * Ho * XML?).
4. Xây dựng cho những gì bạn có, không phải những gì bạn tưởng tượng rằng bạn sẽ có hai năm kể từ bây giờ. Một câu trả lời khác tham khảo YAGNI - chúng hoàn toàn chính xác! Giải quyết các vấn đề tưởng tượng làm cho thời hạn của bạn là tưởng tượng. Đặt mục tiêu vững chắc cho các lần lặp của bạn và đáp ứng chúng. Triển khai! Một dự án đang phát triển là một dự án chỉ có một người dùng - bạn!
5. YMMV (Số dặm của bạn có thể thay đổi). Chỉ có một điều tuyệt đối ở đây: có một vấn đề, bạn đang xây dựng một giải pháp. Mọi thứ khác hoàn toàn trong không khí. Cả hai giải pháp trên đều có thể tạo nên thành công rực rỡ - và thất bại. Tất cả tùy thuộc vào bạn, công cụ của bạn và cách bạn sử dụng chúng. Bước đi nhẹ nhàng, nhà phát triển đồng bào!

Truy cập trực tiếp vào các đối tượng kinh doanh của bạn (tôi cho rằng bạn có nghĩa là trong bộ điều khiển của bạn) sẽ nhanh hơn & dễ dàng hơn.

Điều gì xảy ra nếu khách hàng muốn lưu trữ API và web trên máy chủ đám mây khác nhau và chỉ áp dụng tỷ lệ trên API hoặc có thể anh ta muốn có url khác nhau để truy cập API và Web (có phần hợp lý)

Sau đó, bạn sẽ cần lưu trữ chúng một cách riêng biệt ... nhưng điều đó nghe có vẻ không hợp lý với tôi, chắc chắn bạn sẽ muốn mở rộng cả hai. Bạn có chắc chắn cần phải phục vụ cho yêu cầu này? Nghe có vẻ quá mức cần thiết. Hãy nhớ YAGNI - nếu bạn không cần nó, đừng xây dựng nó. Khi bạn cần nó, xây dựng nó.

Nếu đó là tôi, tôi sẽ xây dựng trang web bằng công nghệ phù hợp nhất với trang web, khi đó (nếu) bạn cần một dịch vụ mà người khác có thể gọi xây dựng riêng biệt.

Tôi sẽ nói; thích gọi MVC qua WebAPI thông qua HTTPClient. Nó tràn ngập logic xung quanh logic "lõi dll" nhưng ưu điểm chính là hệ thống tổng thể của bạn sẽ có một điểm truy cập duy nhất vào các đối tượng miền trên HTTP ... Dù sao đi nữa, với các ứng dụng VÀ chọn ứng dụng Kiến trúc dịch vụ vi mô đã chuyển sang Các khung công tác phía máy khách (AngularJS, v.v.) .... tốt hơn để coi MVC là một khách hàng khác ... và điều khiển nhóm của bạn để quản lý API tốt ...

GIỮ NÓ ĐƠN GIẢN. Hy vọng điều này giúp đỡ. Cảm ơn..