Filosofi Pendekatan Implementasi
pendekatan air terjun
Pendekatan air terjun untuk mengimplementasikan aplikasi membutuhkan seorang desainer untuk berkonsultasi dengan satu atau lebih perwakilan dari organisasi pengguna akhir dan menuliskan semua spesifikasi aplikasi. Biasanya, spesifikasi datang dalam satu set dokumen fungsional atau kasus penggunaan, ditulis sedemikian rupa sehingga pengguna akhir dapat dengan mudah membaca dan memahami dokumen tersebut.
Pengguna akhir menandatangani dokumen-dokumen ini, dan dokumen-dokumen tersebut kemudian dikumpulkan oleh tim desain teknis yang merancang aplikasi, membuat berbagai artefak seperti diagram model kelas, diagram keadaan, diagram aktivitas, dan model data. Tujuan dari fase ini adalah untuk menulis semuanya dengan sangat rinci sehingga pengembang tidak akan kesulitan membuat kode yang diperlukan. Ada penyerahan formal desain ke tim pengembangan dan ke tim uji. Setelah pengiriman, tim pengembangan memulai pengkodean dan tim pengujian menggunakan desain teknis yang dikombinasikan dengan kasus penggunaan untuk membuat kasus pengujian dan skenario pengujian.
Setelah tim pengembang menyelesaikan pengkodean, kode diserahkan ke tim penguji. Tim penguji melakukan pengujian yang telah dirancang berdasarkan persyaratan dan desain terperinci. Masalah apa pun akan diperbaiki oleh tim pengembangan. Setelah proses pengujian dan perbaikan selesai, aplikasi dikirim ke pengguna akhir untuk pengujian penerimaan. Pengguna akhir melakukan pemeriksaan akhir untuk melihat apakah aplikasi memenuhi persyaratan awal. Jika disetujui, dia menyetujui produk jadi dan proyek selesai. Setelah tim pengembang menyelesaikan pengkodean, kode diserahkan ke tim penguji.
Tim penguji melakukan pengujian yang telah dirancang berdasarkan persyaratan dan desain terperinci. Masalah apa pun akan diperbaiki oleh tim pengembangan. Setelah proses pengujian dan perbaikan selesai, aplikasi dikirim ke pengguna akhir untuk pengujian penerimaan. Pengguna akhir melakukan pemeriksaan akhir untuk melihat apakah aplikasi memenuhi persyaratan awal. Jika disetujui, dia menyetujui produk jadi dan proyek selesai. Setelah tim pengembang menyelesaikan pengkodean, kode diserahkan ke tim penguji. Tim penguji melakukan pengujian yang telah dirancang berdasarkan persyaratan dan desain terperinci.
Masalah apa pun akan diperbaiki oleh tim pengembangan. Setelah proses pengujian dan perbaikan selesai, aplikasi dikirim ke pengguna akhir untuk pengujian penerimaan. Pengguna akhir melakukan pemeriksaan akhir untuk melihat apakah aplikasi memenuhi persyaratan awal. Jika disetujui, dia menyetujui produk jadi dan proyek selesai.
Pengguna akhir melakukan pemeriksaan akhir untuk melihat apakah aplikasi memenuhi persyaratan awal. Jika disetujui, dia menyetujui produk jadi dan proyek selesai. Pengguna akhir melakukan pemeriksaan akhir untuk melihat apakah aplikasi memenuhi persyaratan awal. Jika disetujui, dia menyetujui produk jadi dan proyek selesai.
Sebuah proyek dapat memiliki lebih banyak atau lebih sedikit fase saat menggunakan pendekatan air terjun, tetapi fitur utamanya adalah awal dan akhir yang sangat formal dari setiap fase, dengan hasil yang sangat formal.
Keuntungan dari pendekatan waterfall adalah tanggung jawab tim yang bertanggung jawab untuk setiap fase lebih besar. Jelas apa yang harus mereka sampaikan, kapan mereka perlu mengirimkannya, dan kepada siapa mereka harus mengirimkannya. Seringkali, tim pengembangan tidak perlu berinteraksi dengan pengguna. Ini bisa sangat berguna saat mengalihdayakan pengembangan ke negara lain.
Kerugian utama dari pendekatan air terjun adalah bahwa, dalam lingkungan di mana segala sesuatu diatur dengan cara yang sangat formal, fleksibilitas untuk merespons perubahan berkurang. Bahkan bergerak perlu diatur. Sangat sedikit perusahaan yang tampaknya melakukan hal ini secara efektif, sering mengakibatkan kenaikan biaya overhead yang signifikan. Untuk mengelola biaya proyek, beberapa perusahaan bahkan menunda setiap perubahan persyaratan hingga pengiriman aplikasi awal, secara efektif mengirimkan aplikasi yang tidak memenuhi kebutuhan pengguna akhir.
pengembangan yang gesit
Banyak proyek pengembangan perangkat lunak yang berjalan lama melampaui anggaran dan tidak mengirimkan produk tepat waktu. Premis dari filosofi pengembangan perangkat lunak tangkas adalah meminimalkan risiko dengan mengembangkan perangkat lunak dalam kotak waktu singkat, yang disebut iterasi, yang biasanya berlangsung dari satu hingga empat minggu. Setiap iterasi seperti proyek perangkat lunak miniaturnya sendiri dan mencakup semua tugas yang diperlukan untuk melepaskan peningkatan fungsionalitas baru: perencanaan, analisis persyaratan, desain, pengkodean, pengujian, dan dokumentasi. Meskipun iterasi mungkin tidak menambahkan fungsionalitas yang cukup untuk menjamin rilis produk, proyek perangkat lunak tangkas bertujuan untuk dapat merilis perangkat lunak baru di akhir setiap iterasi. Di akhir setiap iterasi, tim mengevaluasi kembali prioritas proyek.
Tujuan pengembangan perangkat lunak yang gesit adalah untuk mencapai kepuasan pelanggan melalui pengiriman perangkat lunak yang berguna secara cepat dan berkelanjutan; selalu bertujuan untuk membangun apa yang dibutuhkan pelanggan; menyambut, daripada menentang, perubahan persyaratan yang terlambat; secara teratur beradaptasi dengan keadaan yang berubah; untuk memiliki kerja sama yang erat dan sehari-hari antara pengusaha dan pengembang, di mana percakapan tatap muka adalah bentuk komunikasi terbaik.
Keuntungan utama dari pengembangan perangkat lunak yang gesit adalah fleksibilitas dalam menghadapi perubahan, selalu bertujuan untuk memberikan sesuai dengan kebutuhan bisnis. Sisi negatifnya, tentu saja, adalah peningkatan kompleksitas pengelolaan ruang lingkup, perencanaan, dan penganggaran. Risiko umum lainnya adalah perhatian terbatas pada dokumentasi (teknis).
Pengembangan Inkremental
Pengembangan perangkat lunak tambahan adalah campuran dari pengembangan tangkas dan air terjun. Aplikasi dirancang, diimplementasikan, dan diuji secara bertahap sehingga setiap peningkatan dapat dikirimkan ke pengguna akhir. Proyek tidak selesai sampai penambahan terakhir selesai. Ini bertujuan untuk mempersingkat kaskade dengan mendefinisikan peningkatan menengah dan menggunakan beberapa keuntungan dari pengembangan tangkas. Berdasarkan umpan balik yang diterima pada kenaikan sebelumnya, penyesuaian dapat dilakukan saat memberikan kenaikan berikutnya. Kenaikan berikutnya dapat terdiri dari kode baru serta modifikasi kode yang disediakan sebelumnya.
Keuntungannya adalah formalitas tetap ada, tetapi manajemen perubahan menjadi lebih mudah. Biaya pengujian dan penggelaran aplikasi berkali-kali akan lebih besar daripada melakukannya sekali saja.
Kontrol Aliran Program
Memilih pendekatan untuk kontrol aliran program adalah tugas yang sangat arsitektural. Tujuannya adalah untuk membuat cetak biru aplikasi Anda di mana, begitu Anda mulai menambahkan fungsionalitas dan kode, semuanya tampak memiliki tempatnya sendiri. Jika Anda pernah meninjau atau menulis kode berkualitas tinggi, Anda memahami prinsip ini.
Kode Penyelenggara
Langkah pertama dalam mendesain alur program adalah mengatur kode dengan menetapkan seperangkat aturan untuk membantu membuat cetak biru, atau garis besar, aplikasi. Maintenance, debugging, dan bug fixing akan lebih mudah karena kode terletak di lokasi yang logis. Setelah melakukan pekerjaan dasar, Anda dapat memilih pendekatan untuk mengimplementasikan logika aplikasi Anda.
Pola desain harus memainkan peran penting dalam desain kontrol aliran program. Selama bertahun-tahun, banyak kode telah ditulis dan banyak solusi telah dirancang untuk masalah berulang. Solusi ini ditata dalam pola desain. Menerapkan pola desain untuk masalah desain perangkat lunak yang umum akan membantu Anda membuat solusi yang mudah dikenali dan dapat diimplementasikan oleh rekan Anda. Masalah unik tetap membutuhkan solusi unik, tetapi Anda dapat menggunakan pola desain untuk memandu Anda menyelesaikannya.
Membuat Proyek
lapisan
Langkah pertama adalah mempertimbangkan lapisan logis. Perhatikan bahwa layer tidak sama dengan layer, seringkali bingung atau bahkan dianggap sama.
lapisan versus lapisan
Lapisan adalah tentang membuat batasan dalam kode Anda. Lapisan atas dapat memiliki referensi ke kode di lapisan di bawahnya, tetapi lapisan tidak akan pernah memiliki referensi ke kode di lapisan di atasnya. Tingkatan mengacu pada distribusi fisik tingkatan di banyak komputer. Misalnya, dalam aplikasi tiga tingkat, UI dirancang untuk berjalan di komputer desktop, logika aplikasi dirancang untuk berjalan di server aplikasi, dan database berjalan di server database. lapisan dapat terdiri dari beberapa lapisan.
Gambar 8-1: Organisasi tiga tingkat dasar
Lapisan mengacu pada tingkat abstraksi. Lapisan yang ditunjukkan pada Gambar 8-1 berlaku untuk sebagian besar aplikasi. Level-level ini juga disebut sebagai tiga lapisan utama dan mungkin memiliki berbagai nama lain. Sebagai aturan, kode di lapisan presentasi dapat memanggil layanan di lapisan logika aplikasi, tetapi lapisan logika aplikasi tidak boleh memanggil metode di lapisan presentasi. Lapisan presentasi tidak boleh secara langsung memanggil lapisan akses data, karena ini akan mengabaikan tanggung jawab yang diterapkan oleh lapisan logika aplikasi. Lapisan akses data tidak boleh memanggil lapisan logika aplikasi.
Lapisan hanyalah abstraksi dan mungkin cara termudah untuk mengimplementasikan lapisan adalah dengan membuat folder di proyek Anda dan menambahkan kode ke folder yang sesuai. Pendekatan yang lebih berguna adalah menempatkan setiap lapisan dalam proyek terpisah, sehingga membuat rakitan terpisah. Manfaat menempatkan logika aplikasi Anda di rakitan perpustakaan adalah memungkinkan Anda membuat pengujian unit, menggunakan Microsoft Visual Studio atau NUnit, untuk menguji logika. Ini juga menciptakan fleksibilitas dalam memilih tempat untuk menerapkan setiap lapisan.
Lapisan Fisik
Dalam aplikasi perusahaan, Anda akan berharap memiliki banyak klien untuk logika yang sama. Faktanya, apa yang membuat aplikasi menjadi aplikasi perusahaan adalah aplikasi itu akan digunakan dalam tiga lapisan: klien, server aplikasi, dan server basis data. Aplikasi Microsoft Office Access yang dibuat oleh departemen penjualan perusahaan Anda, meskipun sangat penting bagi departemen penjualan, bukanlah aplikasi perusahaan.
Perhatikan bahwa lapisan logika aplikasi dan akses data sering digunakan bersama di server aplikasi. Bagian dari perancangan proyek adalah memilih apakah akan mengakses server aplikasi menggunakan layanan .NET atau Web jarak jauh. Apa pun yang Anda pilih, Anda akan menambahkan beberapa kode untuk mengakses layanan jarak jauh dengan mudah di lapisan presentasi. Jika Anda menggunakan layanan web untuk mengakses layanan di server aplikasi Anda, Visual Studio .NET akan melakukan pekerjaan untuk Anda dan menghasilkan kode proksi, secara otomatis menyediakan penerapan pola proksi jarak jauh.
Menambahkan Pola ke Lapisan
Tiga lapisan dasar memberikan ikhtisar tingkat tinggi. Mari tambahkan beberapa pola struktural untuk membuat arsitektur perusahaan yang tangguh. Hasilnya ditunjukkan pada Gambar 8-2.
Fokus pada lapisan logika aplikasi. Gambar 8-2 menunjukkan bahwa pengaksesan logika aplikasi menggunakan pola fasad. Fasad adalah objek yang menyediakan antarmuka yang disederhanakan ke kumpulan kode yang lebih besar, seperti perpustakaan kelas. Fasad dapat mengurangi ketergantungan kode eksternal pada cara kerja perpustakaan karena sebagian besar kode menggunakan fasad, sehingga memungkinkan lebih banyak fleksibilitas dalam pengembangan sistem. Untuk melakukan ini, fasad akan menyediakan antarmuka berbutir kasar ke kumpulan objek berbutir halus.
aliran keputusan
Kontrol aliran program, juga dikenal sebagai aliran keputusan, menyangkut bagaimana Anda mendesain layanan di lapisan logika aplikasi Anda atau, seperti yang Anda lihat di paragraf sebelumnya, bagaimana Anda mendesain metode di fasad Anda.
Ada dua pendekatan untuk mengatur layanan Anda:
- berorientasi pada aksi
- didorong oleh negara
Pendekatan berorientasi tindakan
Dengan mengatur layanan berdasarkan tindakan pengguna, Anda mengimplementasikan logika aplikasi dengan menawarkan layanan, yang masing-masing menangani permintaan khusus dari lapisan presentasi. Ini juga dikenal sebagai pola skrip transaksi. Pendekatan ini populer karena sederhana dan terlihat sangat alami. Contoh metode yang mengikuti pendekatan ini adalah BookStoreService.AddNewOrder(Pesanan pesanan) dan BookStoreService.CancelOrder(int orderId).
Logika yang diperlukan untuk melakukan tindakan diimplementasikan secara berurutan di dalam metode, membuat kode sangat mudah dibaca tetapi juga lebih sulit untuk digunakan kembali. Menggunakan pola desain tambahan, seperti pola modul tabel, dapat membantu meningkatkan kegunaan ulang.
Pendekatan yang didorong oleh negara
Dimungkinkan juga untuk menerapkan alur keputusan aplikasi dengan cara yang jauh lebih berorientasi negara. Layanan yang ditawarkan oleh server aplikasi bersifat lebih umum, misalnya BookStoreService.SaveOrder(Urutan pesanan). Metode ini akan memeriksa status pesanan dan memutuskan apakah akan menambah pesanan baru atau membatalkan pesanan yang sudah ada.
proyek struktur data
Anda harus membuat beberapa pilihan saat mendesain struktur data Anda. Pilihan pertama adalah mekanisme penyimpanan data, yang kedua adalah tujuan penggunaan data, dan yang ketiga adalah persyaratan versi. Ada tiga cara untuk melihat desain struktur data:
- Layanan menawarkan data; data merupakan cerminan dari basis data relasional.
- Data harus dipetakan ke objek dan layanan menyediakan akses ke objek.
- Data yang ditawarkan oleh layanan harus berbasis skema.
Memilih salah satu dari ketiganya sebagai dasar untuk struktur aliran data Anda harus dilakukan pada tahap awal proses desain. Banyak perusahaan memiliki pedoman perusahaan yang mengamanatkan salah satu dari tiga opsi pada semua proyek, tetapi jika memungkinkan, Anda harus mengevaluasi kembali opsi untuk setiap proyek, memilih pendekatan optimal untuk proyek yang ada.
Memilih Mesin Penyimpanan Data
Saat mendesain aplikasi Anda, Anda pasti harus mendesain semacam penyimpanan data. Penyimpanan dan bentuk penyimpanan data berikut tersedia:
- Catatan
- file app.config
- file xml
- file teks biasa
- Basis data
- antrian pesan
Setiap toko memiliki karakteristik uniknya sendiri dan dapat disesuaikan dengan kebutuhan tertentu.
Merancang aliran data
Aliran data menggunakan ADO.NET
Dengan menerapkan layanan pusat data di lapisan logika aplikasi, Anda akan mendesain aliran data Anda menggunakan ADO.NET. Pustaka kelas .NET Framework menyediakan antarmuka pemrograman aplikasi (API) yang ekstensif untuk memanipulasi data dalam kode terkelola. Disebut sebagai ADO.NET, API dapat ditemukan di ruang nama System.Data. Pemisahan lengkap dari pembawa data dan penyimpanan data merupakan fitur desain penting dari ADO.NET. Kelas-kelas seperti DataSet, DataTable, dan DataRow dirancang untuk menyimpan data tetapi tidak mengetahui dari mana asal data tersebut. Mereka dianggap agnostik sumber data. Seperangkat kelas terpisah, seperti SqlConnection, SqlDataAdapter, dan SqlCommand, menangani koneksi ke sumber data, mengambil data, dan mengisi DataSet, DataTable, dan DataRow. Kelas-kelas ini terletak di sub-ruang nama seperti System.Data.Sql, System.Data.OleDB, System.Data.Oracle dan sebagainya. Bergantung pada sumber data mana yang ingin Anda sambungkan, Anda bisa menggunakan kelas di ruang nama yang tepat, dan bergantung pada cakupan produk yang Anda gunakan, Anda akan menemukan bahwa kelas ini menawarkan fungsionalitas yang lebih banyak atau lebih sedikit.
Karena DataSet tidak terhubung ke sumber data, DataSet dapat digunakan dengan cukup berhasil untuk mengelola aliran data dalam aplikasi. Gambar 8-5 menunjukkan aliran data saat melakukan ini.
Mari kita lihat proyek ini dan bayangkan seseorang masuk ke toko buku Anda dan memesan tiga buku. Lapisan presentasi mengelola status keranjang belanja. Pelanggan siap melakukan pemesanan dan telah memberikan semua data yang diperlukan. Dia memilih untuk mengirim pesanan. Halaman web mengubah semua data menjadi Kumpulan Data yang berisi dua Tabel Data, satu untuk pesanan dan satu untuk pesanan; menyisipkan DataRow untuk pesanan; dan menyisipkan tiga DataRows untuk baris pesanan. Halaman web kemudian menampilkan data ini kembali ke pengguna sekali lagi, mengikat kontrol data terhadap Kumpulan Data dan menanyakan Apakah Anda yakin? Pengguna mengonfirmasi permintaan dan dikirim ke lapisan logis aplikasi. Lapisan logika aplikasi memeriksa Kumpulan Data untuk melihat apakah semua bidang wajib memiliki nilai dan melakukan pemeriksaan untuk melihat apakah pengguna memiliki lebih dari 1000 US$. 00 pada tagihan yang belum dibayar. Jika semuanya berjalan lancar, DataSet diteruskan ke lapisan akses data, yang terhubung ke database dan menghasilkan pernyataan sisipan dari informasi DataSet.
Menggunakan DataSet dengan cara ini adalah cara yang cepat dan efisien untuk membangun aplikasi dan menggunakan kekuatan Framework Class Library dan kemampuan ASP.NET untuk mengikat data ke berbagai kontrol seperti GridView terhadap DataSet. Alih-alih menggunakan objek DataSet sederhana, Anda dapat menggunakan objek Typed DataSet dan meningkatkan pengalaman pengkodean dengan mengimplementasikan kode di lapisan presentasi serta lapisan logika aplikasi. Keuntungan dari pendekatan ini juga merupakan kelemahan dari pendekatan tersebut. Perubahan kecil pada model data tidak selalu menyebabkan banyak metode harus mengubah tanda tangan mereka. Jadi dalam hal pemeliharaan, ini bekerja dengan sangat baik. Jika Anda ingat bahwa lapisan presentasi belum tentu merupakan antarmuka pengguna, itu juga bisa berupa layanan web. Dan jika Anda mengubah definisi Kumpulan Data, mungkin karena Anda mengganti nama bidang dalam database, maka Anda mengubah kontrak yang menjadi langganan layanan web. Seperti yang dapat Anda bayangkan, ini dapat menyebabkan beberapa masalah signifikan. Skenario ini bekerja dengan baik jika lapisan presentasi hanyalah antarmuka pengguna, tetapi untuk antarmuka ke sistem atau komponen eksternal, Anda akan ingin menyembunyikan cara kerja bagian dalam aplikasi Anda dan mengubah data menjadi sesuatu selain tiruan langsung dari model data Anda dan Anda ingin membuat Data Transfer Objects (DTO).
Aliran data menggunakan object relational mapping
Aliran data menggunakan ADO.NET adalah pendekatan yang sangat berpusat pada data untuk mengelola aliran data. Data dan logika bersifat diskrit. Ujung lain dari spektrum mengambil pendekatan yang lebih berorientasi objek. Di sini, kelas dibuat untuk mengelompokkan data dan perilaku. Tujuannya adalah untuk menentukan kelas yang meniru data dan perilaku yang ditemukan di domain bisnis tempat aplikasi dibuat. Hasilnya sering disebut sebagai objek bisnis. Kumpulan objek bisnis yang membentuk aplikasi disebut model domain. Beberapa pengembang mengklaim bahwa model domain kaya lebih baik untuk merancang logika yang lebih kompleks. Sulit untuk membuktikan atau menyangkal pernyataan seperti itu. Ketahuilah bahwa Anda punya pilihan dan terserah Anda untuk membuatnya.
Gambar 8-6 menunjukkan aliran data yang mirip dengan Gambar 8-5 , kecuali sekarang Anda telah menambahkan layer pemetaan relasional objek dan mengganti objek DataSet dengan pembawa data yang berbeda.
Sekarang lakukan langkah demi langkah yang sama seperti sebelumnya; bayangkan seseorang terhubung ke toko buku Anda dan memesan tiga buku. Lapisan presentasi mengelola status keranjang belanja. Pelanggan siap melakukan pemesanan dan telah memberikan semua data yang diperlukan. Dia memilih untuk mengirim pesanan. Halaman web mengubah semua data menjadi DTO, menyimpan data untuk satu pesanan dan dengan tiga baris pesanan, membuat objek sesuai kebutuhan. Halaman web menampilkan data ini kembali ke pengguna sekali lagi, kontrol pengikatan data terhadap DTO menggunakan ObjectDataSource di ASP.NET 2.0 dan bertanya Apakah Anda yakin? Pengguna mengonfirmasi pilihan dan DTO dikirimkan ke lapisan logis aplikasi. Lapisan logika aplikasi mengubah DTO menjadi objek bisnis bertipe Order dengan properti berisi tiga objek OrderLine. Metode Pemesanan. Validate() dipanggil untuk memvalidasi pesanan dan memverifikasi bahwa semua bidang wajib memiliki nilai, dan pemeriksaan dilakukan untuk mengidentifikasi apakah pengguna memiliki lebih dari R$ 1.000,00 dalam slip tertunda. Untuk melakukan ini, pesanan akan memanggil Order.Customer.GetOutstandingBills(). Jika semuanya baik-baik saja, metode Order.Save() akan dipanggil. Permintaan akan melalui lapisan pemetaan relasional objek, di mana permintaan dan baris permintaan dipetakan ke DataTable dalam DataSet, dan DataSet diteruskan ke lapisan akses data, yang terhubung ke database dan menghasilkan pernyataan penyisipan dari informasi di DataSet. Ada, tentu saja, banyak cara di mana pemetaan objek-relasional dapat terjadi, tetapi tidak semuanya akan menyertakan transformasi ke DataSet. Beberapa akan membuat pernyataan penyisipan secara langsung tetapi masih menggunakan lapisan akses data untuk mengeksekusi pernyataan itu.
Seperti yang Anda lihat, beberapa transformasi terjadi. Penggunaan DTO diperlukan karena objek bisnis mengimplementasikan perilaku dan perilaku dapat berubah. Untuk meminimalkan dampak perubahan ini pada lapisan presentasi, Anda perlu mengubah data dari objek bisnis menjadi objek transfer data. Di Jawa, objek transfer data sering disebut sebagai objek nilai.
Keuntungan besar bekerja dengan objek bisnis adalah sangat membantu mengatur kode Anda. Jika Anda melihat kembali logika yang rumit, biasanya sangat mudah dibaca karena hanya ada sedikit kode saluran air. Sisi negatifnya adalah sebagian besar penyimpanan data masih bersifat relasional dan memetakan objek bisnis ke data relasional dapat menjadi sangat rumit.
layanan berbasis skema
Anda baru saja melihat dua kebalikan dalam mengelola aliran data. Banyak variasi yang mungkin. Yang umum adalah varian di mana kumpulan data digunakan sebagai pembawa data dasar UI untuk menyimpan data, tetapi skema terpisah (DTO) digunakan untuk layanan web yang dipanggil dari sistem lain. Lapisan aplikasi mengubah data relasional menjadi skema yang telah ditentukan sebelumnya. Keuntungan utama dari hal ini adalah aplikasi apa pun yang mereferensikan layanan tidak bergantung pada implementasi komponen internal apa pun. Hal ini memungkinkan lebih banyak fleksibilitas dalam pembuatan versi, kompatibilitas mundur dari antarmuka, dan kemampuan untuk mengubah implementasi komponen tanpa mengubah antarmuka layanan.
Tentu saja, Anda dapat menggunakan objek bisnis di aplikasi web dan melewati transformasi DTO, tetapi ini biasanya hanya berfungsi dengan baik jika logika aplikasi diimplementasikan bersama dengan aplikasi web. Ingatlah bahwa untuk memanggil Order.Save() Anda memerlukan koneksi database. Apakah ini diinginkan terserah Anda dan mungkin direktur keamanan Anda.