Seberapa penting untuk membuat lapisan layanan?

68

Saya mulai membangun aplikasi dalam 3 lapisan (DAL, BL, UI) [terutama menangani CRM, beberapa laporan penjualan, dan inventaris].

Seorang kolega mengatakan kepada saya bahwa saya harus pindah ke pola lapisan layanan, bahwa pengembang datang ke pola layanan dari pengalaman mereka dan itu adalah pendekatan yang lebih baik untuk merancang sebagian besar aplikasi. Dia mengatakan akan jauh lebih mudah untuk mempertahankan aplikasi di masa depan dengan cara itu.

Secara pribadi, saya merasa bahwa itu hanya membuat hal-hal menjadi lebih kompleks dan saya tidak bisa melihat banyak manfaat darinya yang akan membenarkan hal itu.

Aplikasi ini memang memiliki ui parsial kecil tambahan yang menggunakan beberapa (tetapi hanya beberapa) fungsi aplikasi desktop jadi saya menemukan diri saya menduplikasi beberapa kode (tapi tidak banyak). Hanya karena beberapa duplikasi kode saya tidak akan mengubahnya menjadi berorientasi layanan, tetapi dia berkata saya harus menggunakannya juga karena secara umum itu adalah arsitektur yang sangat bagus, mengapa programmer sangat bersemangat tentang layanan ??

Saya sudah mencoba google tetapi saya masih bingung dan tidak bisa memutuskan apa yang harus dilakukan.

design-patterns architecture web-services services service BornToCode
sumber

Jawaban:

58

Buku Martin Fowler "Patterns of Enterprise Architecture" menyatakan:

Pertanyaan yang lebih mudah dijawab mungkin saat tidak menggunakannya. Anda mungkin tidak memerlukan Lapisan Layanan jika logika bisnis aplikasi Anda hanya akan memiliki satu jenis klien - misalnya, antarmuka pengguna - dan itu menggunakan respons kasus yang tidak melibatkan banyak sumber daya transaksional. [...]

Tetapi segera setelah Anda membayangkan klien jenis kedua, atau sumber daya transaksi kedua dalam respons use case, ia membayar untuk mendesain dalam Lapisan Layanan dari awal.

Manfaat yang diberikan oleh Lapisan Layanan adalah bahwa ia mendefinisikan serangkaian operasi aplikasi umum yang tersedia untuk klien yang berbeda dan mengoordinasikan respons di setiap operasi. Di mana Anda memiliki aplikasi yang memiliki lebih dari satu jenis klien yang mengkonsumsi logika bisnisnya dan memiliki kasus penggunaan kompleks yang melibatkan banyak sumber daya transaksional - masuk akal untuk menyertakan Lapisan Layanan dengan transaksi terkelola.

Dengan CRM, Penjualan, dan Inventaris akan ada banyak kasus penggunaan tipe CRUD yang hampir selalu ada korespondensi satu-ke-satu dengan operasi Layer Layanan. Respons terhadap pembuatan, pembaruan, atau penghapusan objek domain harus dikoordinasikan dan ditransaksikan secara atomis oleh operasi Lapisan Layanan.

Manfaat lain dari memiliki Lapisan Layanan adalah ia dapat dirancang untuk pemanggilan lokal atau jarak jauh, atau keduanya - dan memberi Anda fleksibilitas untuk melakukannya. Pola tersebut meletakkan fondasi untuk penerapan enkapsulasi logika bisnis aplikasi dan permohonan logika tersebut oleh berbagai klien secara konsisten. Ini berarti Anda juga mengurangi / menghapus duplikasi kode, karena klien Anda berbagi layanan umum yang sama. Anda berpotensi mengurangi biaya pemeliharaan juga - karena ketika logika bisnis Anda berubah, Anda (umumnya) hanya perlu mengubah layanan, dan bukan masing-masing klien.

Singkatnya, bagus untuk menggunakan Lapisan Layanan - lebih-jadi saya pikir dalam contoh Anda, Anda telah menyediakan karena sepertinya Anda memiliki banyak klien logika bisnis.

Deco
sumber
2
Menariknya, Martin Fowler mendukung antarmuka yang sama untuk pemanggilan lokal dan jarak jauh, dengan alasan bahwa perbedaan kinerja yang sangat besar dalam pemanggilan jarak jauh memaksa antarmuka yang lebih berbutir kasar.
psr
Saya tidak begitu mengerti paragraf Anda With CRM, Sales and Inventory there will be a lot of CRUD-type use cases of which there is almost always a one-to-one correspondence with Service Layer operations- jika ini semua tentang beberapa UI jadi bagaimana cara CRUD masuk ke sini? Dan jika saya tidak membutuhkan banyak UI meskipun CRUD berjalan baik dengan layanan, saya masih tidak akan membuat lapisan layanan, jika saya mengerti dengan benar, dan saya benar-benar berharap saya melakukannya karena saya lebih suka untuk menjaga hal-hal sederhana (lapisan layanan adalah mengacaukan pendapat saya yang belum berpengalaman)
BornToCode
4
Dalam kasus seperti itu, jarang ada hanya satu klien yang dapat memanfaatkannya. Jika Anda hanya memiliki satu UI, saya dapat memikirkan dua alasan bahwa Anda mungkin masih menginginkan lapisan layanan: keamanan dan penggunaan kembali. Penyiapan perusahaan tipikal akan membuat aplikasi UI tersedia untuk klien eksternal, dan lapisan layanan Anda hanya tersedia di jaringan. Jadi server web memilah pekerjaan ke bagian yang dikunci dari jaringan Anda. Dalam contoh penjualan, Anda dapat menggunakan kembali jika Anda mengambil penjualan dari situs web Anda dan memperluas ke eBay atau Amazon. Sekarang Anda memiliki satu UI, namun banyak klien.
Phil Patterson
5
Hanya untuk menambahkan komentar dari @ PhilPatterson. Banyak klien tidak hanya harus berbasis UI. Pikirkan layanan web atau perpustakaan - mereka juga bisa menjadi klien. UI ujung depan Anda mungkin menggunakan lapisan layanan serta layanan perangkat lunak yang Anda paket dan membiarkan orang lain menggunakannya.
Deco
dapatkah Anda memberikan contoh Lapisan Layanan?
user962206
34

Menambahkan lapisan layanan karena Anda telah mengevaluasi ide dan menyimpulkan itu pendekatan terbaik: bagus

Menambahkan lapisan layanan karena itulah yang dilakukan semua anak keren: buruk

Jika perut Anda mengatakan Anda tidak membutuhkannya, maka jangan membuatnya.

Salah satu perkembangan yang lebih mengecewakan dalam dunia pemrograman selama lebih dari 10 tahun terakhir adalah bahwa ia telah menjadi berorientasi 'mode' yang menjengkelkan, dengan orang-orang mengikuti tren dan kereta musik seolah-olah mereka adalah sepatu musim ini. Jangan jatuh ke dalam perangkap itu. Karena 'semua orang' musim depan akan memberi tahu Anda bahwa Anda harus mendesainnya dengan cara lain.

Tidak ada yang salah atau benar dengan lapisan layanan - ini adalah pendekatan khusus yang kesesuaiannya harus dievaluasi berdasarkan kemampuan teknisnya untuk proyek yang sedang ditangani. Jangan merasa harus mengganti pendapat orang lain dengan penilaian Anda sendiri.

GrandmasterB
sumber
27
Ini tidak membahas masalah subjek sama sekali, itu hanya membuat pernyataan / kata-kata kasar tentang praktik pembangunan yang, setelah mengganti beberapa kata, dapat berlaku untuk hampir semua pertanyaan di situs ini. Dari membaca jawaban ini, saya bahkan tidak yakin bahwa Anda tahu persis apa lapisan layanan itu .
Aaronaught
12
Ini tentu bisa diterapkan pada pertanyaan lain ... tidak membuatnya kurang benar. Faktanya, baik Anda maupun saya tidak memiliki konteks yang dekat untuk menyatakan apa yang dia butuhkan dalam proyeknya, jadi katakan padanya ya dia membutuhkannya, atau tidak, dia tidak, hanya tebakan yang tidak tepat dan tidak profesional. Apa yang dibutuhkan OP di sini adalah sedikit dukungan moral untuk membuat keputusan yang dia tahu adalah yang benar.
GrandmasterB
5
@Aronaught Terlepas dari kebenaran jawaban, dia pada dasarnya masih menjawab pertanyaan utama, "Seberapa penting lapisan layanan?". Dia mengklaim tidak penting sama sekali dan itu mungkin hanya iseng saja. Jika Anda tidak setuju dengan jawabannya maka harap unduh.
maple_shaft
2
@ GrandmasterB Saya berpendapat bahwa mode bagus dalam pengembangan perangkat lunak. Sebagian besar pengembang terlalu segar atau terlalu tidak kompeten untuk membuat keputusan desain dan arsitektur yang terinformasi dengan baik. Kami masih berharap mereka menghasilkan beberapa kemiripan perangkat lunak yang bekerja, jadi mereka melompat pada kereta musik dan konsisten dengan pilihan desain yang buruk jauh lebih disukai dan lebih dapat dipertahankan daripada cara yang dilakukan tahun lalu di mana kita akan koboi kode di semua yang mereka tidak mengerti atau menghargai.
maple_shaft
10
@maple_shaft Hanya untuk memperjelas, saya tidak mengatakan Layers Layanan adalah tren. Saya mengatakan, berdasarkan cara pertanyaan itu diajukan, bahwa tampaknya ada perilaku aneh / mode / ikut-ikutan di pihak rekan-rekannya untuk mendorongnya menggunakan arsitektur yang menurutnya tidak warrented dalam proyeknya. Saya membuatnya jelas dalam jawaban saya, saya melihat Layers Layanan (atau konsep lain) sebagai hanya itu - konsep netral yang kesesuaiannya harus dievaluasi berdasarkan kemampuan mereka sendiri untuk masing-masing proyek. Mereka tidak boleh diterapkan / digunakan ketika penilaian seseorang mengatakan mereka tidak diperlukan.
GrandmasterB
22

Ada banyak faktor yang masuk ke keputusan membuat lapisan layanan. Saya telah membuat lapisan layanan di masa lalu karena alasan berikut.

  1. Kode yang perlu digunakan kembali oleh banyak klien.
  2. Perpustakaan pihak ketiga yang kami miliki lisensinya terbatas.
  3. Pihak ketiga yang membutuhkan titik integrasi ke dalam sistem kami.
  4. Memusatkan logika bisnis yang digandakan.

Kasus 1: Anda membuat fungsionalitas dasar yang perlu digunakan oleh banyak klien yang berbeda. Lapisan layanan membangun fungsionalitas untuk klien yang berbeda untuk memanfaatkan fungsionalitas Anda yang disediakan langsung dari kotak.

Kasus 2: Anda biasanya meng-host kode di ruang aplikasi tetapi Anda menggunakan perpustakaan pihak ketiga yang memiliki lisensi terbatas untuk Anda. Dalam hal ini Anda memiliki sumber daya yang ingin Anda gunakan di mana-mana, tetapi hanya dalam jumlah terbatas. Jika Anda meng-host-nya di balik layanan, maka seluruh organisasi Anda dapat menggunakannya dari aplikasi mereka tanpa harus membeli lisensi untuk setiap hosting.

Kasus 3: Anda sedang membangun fungsionalitas untuk pihak ketiga untuk berkomunikasi dengan Anda. Dalam contoh Anda, Anda dapat mengatur titik akhir inventaris untuk memungkinkan vendor menyampaikan pesan kepada Anda tentang pengiriman produk yang masuk.

Kasus 4: Anda telah menganalisis perusahaan kode Anda secara luas dan menemukan bahwa tim yang terpisah telah menciptakan hal yang sama (hanya diterapkan sedikit berbeda). Dengan lapisan layanan, Anda dapat memilih pendekatan terbaik dan sekarang Anda dapat menerapkan proses yang sama di semua tim dengan meminta mereka masuk ke dalam layanan. Manfaat lain untuk memusatkan logika adalah ketika bug ditemukan. Sekarang Anda dapat menggunakan perbaikan sekali dan semua klien menikmati manfaatnya pada saat bersamaan.

Semua ini dikatakan ada potensi negatif ke lapisan layanan.

  1. Menambahkan kompleksitas sistem. Di mana sebelumnya Anda hanya memiliki satu aplikasi untuk debug sekarang Anda memiliki dua. Masalah produksi memerlukan pemeriksaan pengaturan aplikasi klien, pengaturan aplikasi layanan, atau masalah komunikasi antara pengaturan klien dan server dengan benar. Ini bisa rumit jika Anda belum pernah melakukannya sebelumnya.
  2. Satu titik kegagalan. Jika Anda memiliki pemadaman layanan, semua klien akan terpengaruh. Ketika kode tidak digunakan dengan cara ini risikonya bisa lebih sedikit (meskipun ada cara untuk mengurangi ini).
  3. Versi bisa lebih sulit dilakukan. Ketika Anda memiliki satu aplikasi menggunakan perubahan antarmuka penggunaan layanan dapat dilakukan pada saat yang sama antara keduanya. Saat Anda memiliki banyak klien sekarang, Anda harus mengelola siapa yang ada di V1, siapa yang ada di V2, dan mengoordinasikan penghapusan V1 (setelah Anda tahu semua orang telah memperbarui ke V2).

Poin utamanya adalah tidak selalu sulit untuk membuat layanan sistem Anda berorientasi. Dalam pengalaman saya, biasanya itu ide yang bagus (saya cenderung membuat struktur aplikasi dengan cara ini), tetapi ini bukan keputusan otomatis. Pada akhirnya Anda harus mempertimbangkan pro dan kontra dan membuat keputusan yang tepat untuk situasi Anda.

Phil Patterson
sumber
2
+1 Terima kasih atas jawaban yang informatif. Saya benar-benar ragu cuaca untuk menerima jawaban Anda atau jawaban Deco. Akhirnya karena saya tidak terlalu berpengalaman, saya memutuskan untuk memilih jawaban yang paling banyak mendapat dukungan. Saya masih merasa bahwa jawaban Anda pantas mendapatkan lebih banyak suara. Bagaimanapun, saya sangat menghargai Anda membagikan pengetahuan dan pengalaman Anda. Terima kasih!
BornToCode
1
Sama-sama! Poin utama untuk menghilangkan kedua jawaban adalah bahwa ini (terutama) tentang menyelesaikan masalah pemeliharaan dengan memiliki banyak klien yang perlu melakukan hal yang sama. Semakin banyak klien yang menggunakan layanan ini, semakin besar pula keuntungan perawatannya untuk Anda.
Phil Patterson
1
Ada juga keamanan - lapisan layanan dapat memberikan tembok lain bagi peretas untuk melanggar untuk sampai ke harta karun di DB. Kurangnya lapisan layanan mungkin mengapa begitu banyak situs web mendapatkan pelanggaran besar, dengan layanan di tengahnya, para peretas akan mendapatkan data yang jauh lebih sedikit sebelum mereka terdeteksi.
gbjbaanb
6

Sebagian besar Lapisan Layanan yang saya lihat berantakan total. Layanan cenderung memiliki banyak metode berbeda, 1500 LOC tidak jarang. Metode yang berbeda tidak memiliki kesamaan, tetapi lakukan kode berbagi. Ini menghasilkan kopling tinggi , kohesi rendah . Itu juga melanggar OCP , karena setiap kali operasi baru diperlukan, Anda harus memodifikasi kode alih-alih memperluas basis kode. Lapisan layanan yang dibangun dengan baik secara teori dimungkinkan, tetapi saya tidak pernah melihatnya dalam praktik.

CQRS memecahkan masalah ini dan mencegah Anda dari keharusan membuat salah satu dari lapisan layanan prosedural tersebut.

Jeroen
sumber
2
Dibangun dengan baik oleh standar siapa? Tentu saja dengan standar OO antarmuka lapisan layanan adalah trainwreck lengkap berantakan. Dari perspektif fungsional atau prosedural maka mendorong pendekatan desain berlapis yang indah. Saya pikir orang-orang hang up terbesar dengan lapisan layanan adalah bahwa mereka mendorong aplikasi berbasis transaksi stateless dan mencegah pendekatan berorientasi objek murni. Saya bisa memahami kedua sisi argumen.
maple_shaft
6

Menambahkan antarmuka (lapisan layanan adalah jenis antarmuka) membutuhkan waktu. Yang bagus membutuhkan banyak waktu untuk merancang dan menguji. Sangat penting untuk melakukannya dengan benar pada percobaan pertama karena mengubahnya nanti akan menghancurkan semua klien. Juga, pertimbangkan bahwa Anda mungkin tidak akan tahu apa yang perlu ada di antarmuka itu sampai Anda memiliki klien kedua dengan kebutuhan yang sedikit berbeda. Mempertahankan layanan adalah proyek yang tidak pernah berakhir.

Di sebagian besar organisasi, jika Anda pergi ke sponsor bisnis Anda dan bertanya kepada mereka, "Apakah Anda ingin departemen lain mendapatkan manfaat dari (menggunakan kembali) sistem yang kami kembangkan dengan anggaran Anda?" mereka akan menertawakanmu. Dapatkan itu berfungsi untuk sponsor bisnis Anda terlebih dahulu, kemudian mulai bermain-main dengan menggunakan kembali kode itu (pada waktu departemen Anda sendiri).

Jika Anda tahu, pada kenyataannya, bahwa fungsionalitas yang Anda tulis hari ini akan digunakan kembali oleh beberapa klien layanan yang berbeda, maka pertimbangkan untuk merancang lapisan layanan sejak hari pertama. Jika Anda tidak yakin, atau sudah ada banyak yang tidak diketahui dalam proyek ini, dapatkan sesuatu yang sederhana terlebih dahulu dan pisahkan menjadi layanan dan klien nanti jika Anda punya waktu dan anggaran. Jauh lebih mudah untuk mendapatkan antarmuka layanan tepat pada percobaan pertama ketika Anda mulai dengan sistem kerja.

PS Jika Anda bekerja di Jawa, Joshua Bloch memiliki banyak saran antarmuka yang fantastis di seluruh bukunya, Java Efektif.

GlenPeterson
sumber
Jawaban yang bagus tanpa teori steril.
danilo
2

Saya setuju denganmu. Tidak perlu menyertakan satu layer lagi jika Anda menggunakan UI tunggal.

DAL, BL dan UI / Controller adalah kombinasi yang baik untuk merancang aplikasi. Jika Anda berencana untuk menggunakan UI tunggal, tidak perlu menyiapkan lapisan tambahan. Termasuk 1 lapisan lagi ke dalam aplikasi hanya meningkatkan upaya pengembangan / waktu.

Schenerio lain adalah menggunakan beberapa UI dalam aplikasi Anda, ada baiknya memiliki lapisan layanan untuk menangani UI dalam kasus ini.

Stack Overflow: Diskusi tentang pola lapisan layanan

Satish Pandey
sumber
Jadi, apakah Anda menyarankan bahwa pada setiap aplikasi kompleks yang dikembangkannya ia harus menggunakan lapisan layanan dan tidak hanya puas dengan lapisan DAL, BL, UI?
BornToCode
Dalam hal beberapa UI, kita harus menyertakan lapisan layanan. Dalam kasus Anda saya tidak berpikir ada kebutuhan untuk menyiapkan layer baru. Ini hanya meningkatkan kompleksitas aplikasi.
Satish Pandey
0

Saya akan berpendapat bahwa BL Anda adalah lapisan layanan Anda. Tempat sentral tempat logika bisnis Anda berada. Ini harus DLL yang dapat digunakan oleh apa pun yang membutuhkan logika itu. Kemudian Anda dapat meletakkan layer web api di atasnya jika aplikasi Anda memiliki UI yang berbeda.

pengguna441521
sumber