Haruskah kita memanggil API Web dari aplikasi MVC dalam solusi yang sama?


33

Saya sedang mengerjakan sebuah proyek di MVC yang memiliki aplikasi seluler jadi satu hal yang jelas bahwa kita harus menggunakan Web API sehingga dapat digunakan dalam aplikasi seluler.

Setelah membuat API ketika kami mulai mengembangkan situs Web, kami bingung dan berdiskusi apakah akan menggunakan API atau langsung mengakses objek Bisnis. Dan kami berakhir setelah memiliki formulir pendapat pengembang yang lebih berpengalaman untuk mengkonsumsi Web API daripada menggunakan objek Bisnis secara langsung.

Saya mengalami kebingungan mengenai struktur solusi ini.

1) Mengapa kita harus menggunakan API Web dan membuat permintaan HTTP (yang memakan waktu) untuk mendapatkan atau menempatkan data alih-alih objek bisnis secara langsung yang berada dalam solusi yang sama.

2) Setelah berdebat mereka mengatakan bagaimana jika klien ingin meng-host API dan web di server cloud yang berbeda dan menerapkan penskalaan hanya pada API atau mungkin dia ingin memiliki url berbeda untuk mengakses API dan Web (yang menurut logika). Jadi dalam hal ini kita harus memanggil Web API dari aplikasi MVC dalam solusi yang sama?

3) Jika kita hosting API dan Web pada hosting yang berbeda maka itu berarti Web kita akan menggunakan WebClient dan memiliki panggilan HTTP pada setiap navigasi. Apakah tepat?

4) Jika kita akan objek bisnis membentuk API dan hosting Web pada server yang berbeda maka jika ada perubahan pada BL akan perlu memperbarui build di kedua server.

5) Atau kita harus membuat hanya satu proyek untuk API dan dapat menambahkan tampilan atau halaman html untuk mengembangkan antarmuka Web sehingga dengan cara itu kita dapat langsung memanggil API dari ajax.

Sesuai pengetahuan saya # 5 adalah solusi terbaik atau API hanya untuk akses pihak ke-3. Jika kita memiliki DB, EF, lapisan data dan lapisan bisnis dalam solusi yang sama maka kita tidak boleh menggunakan API untuk melakukan panggilan HTTP dan secara langsung mengakses objek bisnis. (koreksi saya jika saya salah) API diperlukan ketika aplikasi seluler atau desktop atau siapa pun ingin mengakses aplikasi sehingga kami dapat memiliki repositori dan lapisan data yang sama.

Dalam skenario saya, saya harus membuat API karena kami juga memiliki aplikasi seluler, dan di sisi API proyek kami menyebutnya lapisan bisnis (proyek terpisah) dan lapisan bisnis berkomunikasi ke lapisan akses data (proyek terpisah). Jadi pertanyaan saya adalah apakah kita meng-host API dan web kita ke server yang berbeda kemudian memanggil API yang merupakan permintaan HTTP mungkin membutuhkan waktu lebih lama daripada menggunakan metode dari lapisan bisnis saat kita membuat proyek dan kita sudah .dll dari lapisan bisnis. Dalam kontroler API kami hanya mengonversi put bisnis kami ke format json.

Saya sudah mencari di internet tetapi tidak mendapatkan jawaban yang meyakinkan. Saya telah menemukan blog http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx membahas hal yang sama tetapi sekali lagi di blog itu pertanyaan saya adalah mengapa kita perlu mempertimbangkan skenario # 3?

Pembaruan: Kami dapat memiliki proyek API dan proyek MVC yang berbeda dan kami dapat memanggil API dari web menggunakan jvascript atau dapat menggunakan pola MVVM.


MVVM atau MVC dengan model tampilan?
Andrew Hoffman

Kami menggunakan MVC
Ruchir Shah

Baiklah kalau begitu, maka tidak ada jawaban yang benar. Ada manfaatnya memanggil API Anda hanya untuk meningkatkan kualitasnya. (makan dogfood Anda sendiri) Ada juga manfaat kinerja untuk melakukan panggilan inproc daripada menelepon melalui layanan.
Andrew Hoffman

Google pernah membahas pertanyaan ini sekali. Produk mereka adalah layanan dan situs web. Saya percaya mereka memutuskan untuk membuat situs web mereka menggunakan layanan mereka sendiri.
Andrew Hoffman

2
Iya nih. programmers.stackexchange.com/questions/148556/… dan stackoverflow.com/questions/3590561/… adalah sumber yang bagus. Ada yang melakukannya, ada yang tidak. Tidak ada cara 'benar' yang sebenarnya.
Andrew Hoffman

Jawaban:


37

Pertanyaan bagus! Saya selalu mencari cara yang lebih baik untuk menyusun proyek saya .. Setiap poin yang Anda ajukan memiliki kelebihan dan setelah menjelajahi berbagai struktur solusi, saya harus mengatakan bahwa saya menyetujui sebagian besar komentar di sini: tidak ada solusi yang sempurna. Beberapa hal yang perlu Anda tanyakan pada diri sendiri ketika menghadapi masalah seperti ini: Seberapa kompleks aplikasi ini? Dengan berapa banyak sistem yang perlu saya integrasikan - atau berapa banyak sistem yang perlu diintegrasikan dengan sistem ini? Berapa banyak pengujian yang saya rencanakan untuk dilakukan? Apakah ada tim desain / UI yang terpisah? Apakah kita perlu skala? Apa yang dimaksud dengan sesi?

Mari kita simak beberapa skenario dan cara-cara menggunakan teknik yang sedikit pintar untuk membuat segalanya benar-benar menggedor (dan beberapa trik untuk membuat segalanya lebih mudah) ..

Hosting API dan Situs Web dalam Proyek yang Sama
Dalam hal ini, Anda mungkin memiliki solusi tunggal dengan nol atau lebih proyek lapisan bisnis dan proyek MVC / WebAPI hibrid tunggal (serta proyek lainnya - utilitas, dll.).


Semuanya Pro ada di satu tempat .. Tidak perlu bersusah payah dalam pesan yang rumit (panggilan HttpClient), Anda dapat berbagi status sesi (klien dan server melalui cookie, sesi InProc / OutOfProc, dll), pengumpulan koneksi, logika bersama, dll. Penempatan tidak bisa lebih sederhana.


Semuanya Con di satu tempat .. Ini mungkin struktur yang paling monolitik mungkin. Tidak ada antarmuka yang jelas antara lapisan Anda .. Anda berakhir dengan kohesi tinggi . Pengembang malas akan menghindari antarmuka saat berhadapan dengan arsitektur jenis ini yang membuat pengujian sangat menyusahkan. Menandai / co-locating aplikasi akan sulit.

Penggunaan
Saya akan menggunakan struktur proyek ini untuk aplikasi satu kali, internal, atau sederhana. Membangun sistem cepat untuk melacak pendaftaran kamp basket di Y setempat? Ini adalah arsitektur Anda!

WebAPI dan Situs Web dalam Berbagai Proyek
Saya cenderung lebih suka kasus ini .. Anda memiliki solusi tunggal dengan satu (atau lebih) proyek MVC dan satu proyek WebAPI.


Modularisasi Pro ! Kopling longgar! Setiap proyek dapat berdiri sendiri, diuji secara terpisah, dan dapat dikelola secara berbeda. Ini memungkinkan Anda untuk lebih mudah menerapkan berbagai strategi caching tergantung pada kebutuhan Anda. Dengan menjaga batas-batas yang solid antara sistem yang berbeda, Anda dapat lebih mudah membuat kontrak yang memungkinkan Anda untuk menegakkan pola penggunaan spesifik dan mengurangi kemungkinan gesekan (baca: lebih sedikit bug dengan lebih sedikit peluang untuk menyalahgunakan API). Penskalaan sedikit lebih mudah karena Anda hanya perlu skala bit yang melihat beban tinggi. Integrasi menjadi sedikit lebih mudah untuk ditangani juga karena Anda perlu memiliki gagasan tentang bagaimana API Anda akan terlihat seperti dari awal.

Con's
Maintenance sedikit lebih sulit. Banyak proyek berarti Anda akan memerlukan pemilik proyek / fitur untuk melacak penggabungan, kontrak (antarmuka), penyebaran, dll. Pemeliharaan kode, utang teknis , pelacakan kesalahan, manajemen negara - semua menjadi perhatian karena mereka mungkin perlu diimplementasikan secara berbeda berdasarkan sesuai kebutuhan anda. Aplikasi semacam ini juga membutuhkan perencanaan dan kurasi yang paling besar saat mereka tumbuh.

Penggunaan
Membangun aplikasi yang bisa memiliki 100 pengguna hari ini dan 100.000 minggu depan / bulan? Apakah aplikasi harus mengirim pemberitahuan, mengelola alur kerja yang rumit, dan memiliki banyak antarmuka (aplikasi web + seluler + SharePoint)? Punya banyak waktu di tangan Anda dan suka memecahkan lebih dari 5.000 puzzle teka-teki selama akhir pekan? Ini adalah arsitektur untuk Anda!

Tips
Setelah menguraikan hal di atas, saya bisa mengerti bagaimana proyek Anda berikutnya mungkin terlihat sedikit menakutkan. Jangan khawatir, berikut adalah beberapa trik yang saya pelajari selama bertahun-tahun ..

  1. Cobalah untuk menggunakan sesi tanpa kewarganegaraan. Pada sistem yang lebih kecil, ini mungkin berarti menyimpan cookie terenkripsi yang mengandung setidaknya id internal pengguna saat ini dan batas waktu. Sistem yang lebih besar mungkin berarti menyimpan cookie terenkripsi dengan id sesi sederhana yang dapat diambil dari datastore (redis, penyimpanan tabel, DHT , dll). Jika Anda dapat menyimpan informasi yang cukup sehingga Anda tidak perlu menekan database utama pada setiap permintaan maka Anda akan berada di tempat yang baik - tetapi cobalah untuk menjaga cookie di bawah 1k.
  2. Ketahuilah bahwa mungkin akan ada lebih dari satu model. Cobalah untuk berpikir dalam hal model dan proyeksi (tautan yang saya temukan di sini adalah .. tidak baik .. pikirkan: item persediaan satu orang adalah item baris pesanan orang lain - struktur dasar yang sama, tetapi pandangan yang berbeda). Beberapa proyek memiliki model yang berbeda untuk setiap batas logis / konseptual (yaitu menggunakan model spesifik untuk komunikasi dengan API tertentu.
  3. API Di Mana Saja! Kapan saja objek / kelas / struktur memperlihatkan data atau perilaku apa pun, Anda membuat API. Perhatikan bagaimana entitas atau dependensi lainnya akan menggunakan API ini. Pikirkan tentang bagaimana Anda dapat menguji API ini. Pertimbangkan apa yang mungkin berbicara dengan API ini (objek lain melalui kode? Sistem lain melalui protokol?) Dan bagaimana data itu diekspos (sangat diketik? JSON? * Batuk * XML?).
  4. Bangun untuk apa yang Anda miliki, bukan apa yang Anda bayangkan akan Anda miliki dua tahun dari sekarang. Referensi jawaban lain YAGNI - mereka benar sekali! Memecahkan masalah imajiner membuat tenggat waktu Anda imajiner. Tetapkan tujuan yang solid untuk iterasi Anda dan penuhi. Menyebarkan! Sebuah proyek dalam pengembangan adalah proyek dengan hanya satu pengguna - Anda!
  5. YMMV (Mileage Anda Mungkin Bervariasi). Hanya ada satu absolut di sini: ada masalah, Anda sedang membangun solusi. Segala sesuatu yang lain benar-benar ada di udara. Kedua solusi di atas dapat dibuat sukses liar - dan kegagalan mengisap. Semuanya terserah Anda, alat Anda, dan bagaimana Anda menggunakannya. Tapak ringan, sesama pengembang!

2
Jawaban bagus! Saya berharap saya bisa memberi Anda sesuatu untuk tulisan Anda, tetapi karena saya tidak bisa memikirkan apa pun, saya hanya akan mengikuti Twitter Anda. : P
Dan

"sangat diketik? JSON? * cough * XML" apa yang saya lewatkan?
Alexander Derck

1
@AlexanderDerck Saya menyebutkan tiga opsi pemformatan yang berbeda (walaupun ada lebih banyak) .. "lelucon" adalah bahwa XML bisa sulit untuk bekerja dengan dan sering dapat menambahkan sedikit overhead yang baik (serialisasi / deserialisasi). Itu bukan untuk mengatakan bahwa kadang-kadang tidak ada kebutuhan (terutama ketika bekerja dengan kelompok-kelompok eksternal) ..
Bobby D

6

Langsung mengakses objek bisnis Anda secara langsung (saya asumsikan maksud Anda di controller Anda) akan lebih cepat & mudah.

bagaimana jika klien ingin meng-host API dan web di server cloud yang berbeda dan menerapkan penskalaan hanya pada API atau mungkin ia ingin memiliki url berbeda untuk mengakses API dan Web (yang agak logis)

Maka Anda harus meng-host mereka secara terpisah ... tapi itu tidak terdengar sangat logis bagi saya, tentunya Anda ingin mengatur keduanya. Apakah Anda yakin harus memenuhi persyaratan ini? Kedengarannya seperti berlebihan. Ingat YAGNI - jika Anda tidak membutuhkannya, jangan membangunnya. Saat Anda membutuhkannya, bangunlah.

Jika itu saya, saya akan membangun situs menggunakan teknologi yang paling cocok dengan situs tersebut, maka ketika (jika) Anda membutuhkan layanan yang orang lain dapat menyebutnya membangun itu secara terpisah.


Saya benar-benar setuju dengan Anda karena penskalaan pada akhir hari itu penting dan pemisahan kekhawatiran itu penting bagi saya. Itu selalu baik untuk berpikir membangun arsitektur n-tier karena perubahan teknologi yang dapat ditingkatkan atau dipelihara dengan mudah. Misalnya, membungkus dengan wadah buruh pelabuhan adalah hal lain yang perlu dipertimbangkan di masa depan.
Ishwor Khanal

4

Saya akan mengatakan; lebih suka panggilan MVC WebAPI melalui HTTPClient. Ini luar biasa pergi sekitar "inti dll" logika tetapi keuntungan utama adalah bahwa sistem Anda secara keseluruhan akan memiliki satu titik akses ke objek domain di HTTP ... Anyways down the line .. dengan Arsitektur Layanan Mikro mengambil-up DAN aplikasi sudah beralih ke Kerangka Sisi Klien (AngularJS dll.) .... lebih baik memperlakukan MVC sebagai klien lain ... dan memuridkan tim Anda untuk mengelola API dengan baik ...

TETAPI SIMPE. Semoga bantuan ini. Terima kasih..


Tidak yakin mengapa ini tidak dipilih tetapi ini adalah jawaban terbaik untuk imo arsitektur yang bagus
weagle08

Saya merenungkan situasi saya di mana saya pikir itu ide yang baik untuk memanggil API dari aplikasi MVC sendiri - tapi saya pikir itu berbeda dari ini dan mungkin banyak pertanyaan lain yang merujuk pada panggilan ini dari logika server. Dalam kasus saya, saya akan benar-benar memanggilnya dari pandangan saya di mana saya akan meminta Vue membentuk UI kompleks dan meneruskan data ke API itu. Kemudian saya menyadari bahwa itu sah karena dalam kasus saya itu benar-benar memanggil dari tampilan vs item sisi server dan setiap panggilan http akan tetap dilakukan ketika mempertimbangkan segala jenis UI - bahkan mungkin lebih dari itu jika dilihat oleh ASP. Tapi, hanya berfungsi di lingkungan JS.
Vasily Hall

Melihat panggilan API secara langsung adalah pemikiran yang baik .... tetapi Tampilan MVC dihasilkan dari Server sehingga Anda juga dapat memproses data dari server terutama yang lebih relevan untuk pemrosesan server) sebelum merender tampilan parsial (Tampilan) ... RESS framework (RESS : Desain Web Responsif + Komponen Sisi-Server) .... TETAPI GUNAKAN TERBAIK MURNI Kerangka Klien (Angular / ReactJS) jika Anda dapat menghindari MVC sepenuhnya ...
Manoj Kumar Bisht
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.