Falsafah Pendekatan Pelaksanaan
pendekatan air terjun
Pendekatan waterfall untuk melaksanakan aplikasi memerlukan pereka bentuk untuk berunding dengan satu atau lebih wakil organisasi pengguna akhir dan menulis semua spesifikasi aplikasi. Lazimnya, spesifikasi datang dalam satu set dokumen berfungsi atau kes penggunaan, ditulis sedemikian rupa sehingga pengguna akhir boleh membaca dan memahami dokumen dengan mudah.
Pengguna akhir menandatangani dokumen ini, dan dokumen itu kemudiannya dikumpulkan oleh pasukan reka bentuk teknikal yang mereka bentuk aplikasi, mencipta pelbagai artifak seperti rajah model kelas, rajah keadaan, rajah aktiviti dan model data. Matlamat fasa ini adalah untuk menulis segala-galanya dengan terperinci sehingga pembangun tidak akan menghadapi masalah mencipta kod yang diperlukan. Terdapat penyerahan rasmi reka bentuk kepada pasukan pembangunan dan kepada pasukan ujian. Selepas penghantaran, pasukan pembangunan memulakan pengekodan dan pasukan ujian menggunakan reka bentuk teknikal dalam kombinasi dengan kes penggunaan untuk mencipta kes ujian dan senario ujian.
Selepas pasukan pembangunan selesai pengekodan, kod diserahkan kepada pasukan ujian. Pasukan ujian melaksanakan ujian yang telah mereka bentuk berdasarkan keperluan dan reka bentuk terperinci. Sebarang isu akan diselesaikan oleh pasukan pembangunan. Setelah proses ujian dan pembetulan selesai, aplikasi dihantar kepada pengguna akhir untuk ujian penerimaan. Pengguna akhir melakukan semakan akhir untuk melihat sama ada aplikasi mematuhi keperluan awal. Jika diluluskan, dia meluluskan produk siap dan projek itu siap. Selepas pasukan pembangunan selesai pengekodan, kod diserahkan kepada pasukan ujian.
Pasukan ujian melaksanakan ujian yang telah mereka bentuk berdasarkan keperluan dan reka bentuk terperinci. Sebarang isu akan diselesaikan oleh pasukan pembangunan. Setelah proses ujian dan pembetulan selesai, aplikasi dihantar kepada pengguna akhir untuk ujian penerimaan. Pengguna akhir melakukan semakan akhir untuk melihat sama ada aplikasi mematuhi keperluan awal. Jika diluluskan, dia meluluskan produk siap dan projek itu siap. Selepas pasukan pembangunan selesai pengekodan, kod diserahkan kepada pasukan ujian. Pasukan ujian melaksanakan ujian yang telah mereka bentuk berdasarkan keperluan dan reka bentuk terperinci.
Sebarang isu akan diselesaikan oleh pasukan pembangunan. Setelah proses ujian dan pembetulan selesai, aplikasi dihantar kepada pengguna akhir untuk ujian penerimaan. Pengguna akhir melakukan semakan akhir untuk melihat sama ada aplikasi mematuhi keperluan awal. Jika diluluskan, dia meluluskan produk siap dan projek itu siap.
Pengguna akhir melakukan semakan akhir untuk melihat sama ada aplikasi mematuhi keperluan awal. Jika diluluskan, dia meluluskan produk siap dan projek itu siap. Pengguna akhir melakukan semakan akhir untuk melihat sama ada aplikasi mematuhi keperluan awal. Jika diluluskan, dia meluluskan produk siap dan projek itu siap.
Projek boleh mempunyai lebih atau kurang fasa apabila menggunakan pendekatan air terjun, tetapi ciri utama ialah permulaan dan penghujung setiap fasa yang sangat formal, dengan penyampaian yang sangat formal.
Kelebihan pendekatan waterfall ialah tanggungjawab pasukan yang bertanggungjawab untuk setiap fasa adalah lebih besar. Jelas perkara yang perlu mereka sampaikan, bila mereka perlu menyampaikannya dan kepada siapa mereka perlu menyampaikannya. Selalunya, pasukan pembangunan tidak perlu berinteraksi dengan pengguna. Ini boleh menjadi sangat berguna apabila menyumber luar pembangunan ke negara lain.
Kelemahan utama pendekatan air terjun ialah, dalam persekitaran di mana segala-galanya diatur dengan cara yang sangat formal, fleksibiliti untuk bertindak balas terhadap perubahan berkurangan. Malah bergerak perlu diatur. Sangat sedikit syarikat nampaknya melakukan ini dengan berkesan, selalunya mengakibatkan peningkatan yang ketara dalam kos overhed. Untuk menguruskan kos projek, sesetengah syarikat malah menangguhkan sebarang perubahan kepada keperluan sehingga penghantaran aplikasi awal, dengan berkesan menyampaikan aplikasi yang tidak memenuhi keperluan pengguna akhir.
pembangunan tangkas
Banyak projek pembangunan perisian yang telah lama berjalan melebihi bajet dan tidak menyampaikan produk tepat pada masanya. Premis falsafah pembangunan perisian tangkas adalah untuk meminimumkan risiko dengan membangunkan perisian dalam kotak masa yang singkat, dipanggil lelaran, yang biasanya berlangsung dari satu hingga empat minggu. Setiap lelaran adalah seperti projek perisian kecilnya sendiri dan merangkumi semua tugas yang diperlukan untuk mengeluarkan penambahan fungsi baharu: perancangan, analisis keperluan, reka bentuk, pengekodan, ujian dan dokumentasi. Walaupun lelaran mungkin tidak menambah kefungsian yang mencukupi untuk menjamin keluaran produk, projek perisian tangkas bertujuan untuk dapat mengeluarkan perisian baharu pada penghujung setiap lelaran. Pada akhir setiap lelaran, pasukan menilai semula keutamaan projek.
Matlamat pembangunan perisian tangkas adalah untuk mencapai kepuasan pelanggan melalui penyampaian perisian berguna yang pantas dan berterusan; sentiasa bertujuan untuk membina apa yang pelanggan perlukan; mengalu-alukan, bukannya menentang, perubahan lewat kepada keperluan; sentiasa menyesuaikan diri dengan keadaan yang berubah-ubah; untuk mempunyai kerjasama yang erat dan harian antara usahawan dan pemaju, di mana perbualan bersemuka adalah bentuk komunikasi yang terbaik.
Kelebihan utama pembangunan perisian tangkas ialah fleksibiliti dalam menangani perubahan, sentiasa bertujuan untuk menyampaikan mengikut keperluan perniagaan. Kelemahan, sudah tentu, adalah peningkatan dalam kerumitan pengurusan skop, perancangan dan belanjawan. Satu lagi risiko biasa ialah perhatian terhad kepada dokumentasi (teknikal).
Perkembangan Bertambah
Pembangunan perisian tambahan ialah gabungan pembangunan tangkas dan air terjun. Aplikasi direka bentuk, dilaksanakan dan diuji secara berperingkat supaya setiap kenaikan boleh dihantar kepada pengguna akhir. Projek tidak disiapkan sehingga kenaikan terakhir selesai. Ia bertujuan untuk memendekkan lata dengan menentukan kenaikan pertengahan dan menggunakan beberapa kelebihan pembangunan tangkas. Berdasarkan maklum balas yang diterima pada kenaikan sebelumnya, pelarasan boleh dibuat apabila menghantar kenaikan seterusnya. Kenaikan seterusnya boleh terdiri daripada kod baharu serta pengubahsuaian kepada kod yang disediakan sebelum ini.
Kelebihannya ialah formaliti kekal, tetapi pengurusan perubahan menjadi lebih mudah. Kos menguji dan menggunakan aplikasi beberapa kali akan lebih besar daripada melakukannya sekali sahaja.
Kawalan Aliran Program
Memilih pendekatan untuk mengawal aliran program adalah tugas yang sangat seni bina. Matlamatnya adalah untuk mencipta pelan tindakan aplikasi anda di mana, sebaik sahaja anda mula menambah fungsi dan kod, semuanya nampaknya mempunyai tempat tersendiri. Jika anda pernah menyemak atau menulis kod berkualiti tinggi, anda memahami prinsip ini.
Kod Penganjur
Langkah pertama dalam mereka bentuk aliran program adalah untuk mengatur kod dengan mewujudkan satu set peraturan untuk membantu mencipta rangka tindakan, atau garis besar, aplikasi. Penyelenggaraan, penyahpepijatan dan pembetulan pepijat akan menjadi lebih mudah kerana kod tersebut terletak di lokasi yang logik. Sebaik sahaja anda telah melakukan kerja asas, anda boleh memilih pendekatan untuk melaksanakan logik aplikasi anda.
Corak reka bentuk harus memainkan peranan penting dalam reka bentuk kawalan aliran program. Selama bertahun-tahun, banyak kod telah ditulis dan banyak penyelesaian telah direka untuk masalah berulang. Penyelesaian ini dibentangkan dalam corak reka bentuk. Menggunakan corak reka bentuk pada masalah reka bentuk perisian biasa akan membantu anda mencipta penyelesaian yang mudah dikenali dan boleh dilaksanakan oleh rakan sebaya anda. Masalah unik masih memerlukan penyelesaian yang unik, tetapi anda boleh menggunakan corak reka bentuk untuk membimbing anda dalam menyelesaikannya.
Mencipta Projek
lapisan
Langkah pertama ialah mempertimbangkan lapisan logik. Ambil perhatian bahawa lapisan tidak sama dengan lapisan, sering keliru atau dianggap sama.
lapisan berbanding lapisan
Lapisan adalah tentang membuat sempadan dalam kod anda. Lapisan atas boleh mempunyai rujukan kepada kod dalam lapisan di bawah, tetapi lapisan tidak boleh mempunyai rujukan kepada kod dalam lapisan di atas. Peringkat merujuk kepada pengedaran fizikal peringkat merentas berbilang komputer. Sebagai contoh, dalam aplikasi tiga peringkat, UI direka bentuk untuk dijalankan pada komputer meja, logik aplikasi direka bentuk untuk dijalankan pada pelayan aplikasi dan pangkalan data berjalan pada pelayan pangkalan data. data khusus dan kod dalam setiap lapisan boleh terdiri daripada beberapa lapisan.
Rajah 8-1: Organisasi tiga peringkat asas
Lapisan merujuk kepada tahap abstraksi. Lapisan yang ditunjukkan dalam Rajah 8-1 berlaku untuk kebanyakan aplikasi. Tahap ini juga dirujuk sebagai tiga lapisan utama dan mungkin mempunyai pelbagai nama lain. Sebagai peraturan, kod dalam lapisan pembentangan boleh memanggil perkhidmatan dalam lapisan logik aplikasi, tetapi lapisan logik aplikasi tidak boleh memanggil kaedah dalam lapisan pembentangan. Lapisan pembentangan tidak boleh memanggil terus lapisan akses data, kerana ini akan memintas tanggungjawab yang dilaksanakan oleh lapisan logik aplikasi. Lapisan akses data tidak boleh memanggil lapisan logik aplikasi.
Lapisan hanyalah abstraksi dan mungkin cara paling mudah untuk melaksanakan lapisan ialah mencipta folder dalam projek anda dan menambah kod pada folder yang sesuai. Pendekatan yang lebih berguna ialah meletakkan setiap lapisan dalam projek yang berasingan, dengan itu mencipta perhimpunan yang berasingan. Faedah meletakkan logik aplikasi anda dalam perhimpunan perpustakaan ialah ia akan membolehkan anda membuat ujian unit, menggunakan Microsoft Visual Studio atau NUnit, untuk menguji logik. Ia juga mewujudkan fleksibiliti dalam memilih tempat untuk menggunakan setiap lapisan.
Lapisan Fizikal
Dalam aplikasi perusahaan, anda menjangkakan mempunyai berbilang pelanggan untuk logik yang sama. Sebenarnya, apa yang menjadikan aplikasi sebagai aplikasi perusahaan ialah ia akan digunakan dalam tiga lapisan: klien, pelayan aplikasi dan pelayan pangkalan data. Aplikasi Microsoft Office Access yang dicipta oleh jabatan jualan syarikat anda, walaupun sangat penting kepada jabatan jualan, bukanlah aplikasi korporat.
Ambil perhatian bahawa logik aplikasi dan lapisan akses data sering digunakan bersama-sama pada pelayan aplikasi. Sebahagian daripada mereka bentuk projek ialah memilih sama ada untuk mengakses pelayan aplikasi menggunakan perkhidmatan .NET atau Web jauh. Mana-mana yang anda pilih, anda akan menambah beberapa kod untuk mengakses perkhidmatan jauh dengan mudah dalam lapisan pembentangan. Jika anda menggunakan perkhidmatan web untuk mengakses perkhidmatan pada pelayan aplikasi anda, Visual Studio .NET akan melakukan kerja untuk anda dan menjana kod proksi, secara automatik menyediakan pelaksanaan corak proksi jauh.
Menambah Corak pada Lapisan
Tiga lapisan asas memberikan gambaran keseluruhan peringkat tinggi. Mari tambahkan beberapa corak struktur untuk mencipta seni bina perusahaan yang mantap. Hasilnya ditunjukkan dalam Rajah 8-2.
Fokus pada lapisan logik aplikasi. Rajah 8-2 menunjukkan bahawa mengakses logik aplikasi menggunakan corak fasad. Fasad ialah objek yang menyediakan antara muka yang dipermudahkan kepada badan kod yang lebih besar, seperti perpustakaan kelas. Fasad boleh mengurangkan kebergantungan kod luaran pada kerja dalaman perpustakaan kerana kebanyakan kod menggunakan fasad, sekali gus membolehkan lebih fleksibiliti dalam pembangunan sistem. Untuk melakukan ini, fasad akan menyediakan antara muka berbutir kasar kepada koleksi objek berbutir halus.
aliran keputusan
Kawalan aliran program, juga dikenali sebagai aliran keputusan, membimbangkan cara anda mereka bentuk perkhidmatan dalam lapisan logik aplikasi anda atau, seperti yang anda lihat dalam perenggan sebelumnya, cara anda mereka bentuk kaedah dalam fasad anda.
Terdapat dua pendekatan untuk mengatur perkhidmatan anda:
- berorientasikan tindakan
- didorong oleh negeri
Pendekatan berorientasikan tindakan
Dengan mengatur perkhidmatan berdasarkan tindakan pengguna, anda melaksanakan logik aplikasi dengan menawarkan perkhidmatan, setiap satunya mengendalikan permintaan khusus daripada lapisan pembentangan. Ini juga dikenali sebagai corak skrip transaksi. Pendekatan ini popular kerana ia mudah dan kelihatan sangat semula jadi. Contoh kaedah yang mengikuti pendekatan ini ialah BookStoreService.AddNewOrder(Order order) dan BookStoreService.CancelOrder(int orderId).
Logik yang diperlukan untuk melaksanakan tindakan dilaksanakan secara berurutan dalam kaedah, menjadikan kod sangat mudah dibaca tetapi juga lebih sukar untuk digunakan semula. Menggunakan corak reka bentuk tambahan, seperti corak modul jadual, boleh membantu meningkatkan kebolehgunaan semula.
Pendekatan dipacu negara
Ia juga mungkin untuk melaksanakan aliran keputusan aplikasi dengan cara yang lebih berorientasikan keadaan. Perkhidmatan yang ditawarkan oleh pelayan aplikasi lebih bersifat generik, contohnya BookStoreService.SaveOrder(Pesanan pesanan). Kaedah ini akan memeriksa status pesanan dan memutuskan sama ada untuk menambah pesanan baharu atau membatalkan pesanan sedia ada.
Projek struktur data
Anda mesti membuat beberapa pilihan semasa mereka bentuk struktur data anda. Pilihan pertama ialah mekanisme penyimpanan data, yang kedua ialah penggunaan data yang dimaksudkan, dan yang ketiga ialah keperluan versi. Terdapat tiga cara untuk melihat reka bentuk struktur data:
- Perkhidmatan menawarkan data; data adalah cerminan pangkalan data hubungan.
- Data mesti dipetakan ke objek dan perkhidmatan menyediakan akses kepada objek.
- Data yang ditawarkan oleh perkhidmatan mestilah berasaskan skema.
Memilih salah satu daripada tiga sebagai asas untuk struktur aliran data anda harus dilakukan pada peringkat awal proses reka bentuk. Banyak syarikat mempunyai garis panduan syarikat yang mewajibkan satu daripada tiga pilihan pada semua projek, tetapi jika boleh, anda harus menilai semula pilihan untuk setiap projek, memilih pendekatan optimum untuk projek yang sedang dijalankan.
Memilih Enjin Penyimpanan Data
Apabila mereka bentuk aplikasi anda, anda sudah pasti perlu mereka bentuk beberapa jenis stor data. Stor dan bentuk storan data berikut tersedia:
- Rekod
- fail app.config
- fail xml
- fail teks biasa
- Pangkalan data
- mesej beratur
Setiap kedai mempunyai ciri uniknya sendiri dan boleh disesuaikan dengan keperluan tertentu.
Mereka bentuk aliran data
Aliran data menggunakan ADO.NET
Dengan melaksanakan perkhidmatan berpusatkan data dalam lapisan logik aplikasi, anda akan mereka bentuk aliran data anda menggunakan ADO.NET. Pustaka kelas Rangka Kerja .NET menyediakan antara muka pengaturcaraan aplikasi (API) yang meluas untuk memanipulasi data dalam kod terurus. Dirujuk sebagai ADO.NET, API boleh didapati dalam ruang nama System.Data. Pengasingan lengkap pembawa data dan stor data ialah ciri reka bentuk penting ADO.NET. Kelas seperti DataSet, DataTable dan DataRow direka untuk menyimpan data tetapi tidak mengekalkan pengetahuan tentang asal data. Mereka dianggap agnostik sumber data. Set kelas yang berasingan, seperti SqlConnection, SqlDataAdapter dan SqlCommand, menjaga sambungan ke sumber data, mendapatkan data dan mengisi Set Data, DataTable dan DataRow. Kelas ini terletak dalam sub-ruang nama seperti System.Data.Sql, System.Data.OleDB, System.Data.Oracle dan sebagainya. Bergantung pada sumber data yang ingin anda sambungkan, anda boleh menggunakan kelas dalam ruang nama yang betul dan bergantung pada skop produk yang anda gunakan, anda akan mendapati bahawa kelas ini menawarkan lebih atau kurang fungsi.
Memandangkan Set Data tidak disambungkan kepada sumber data, ia boleh digunakan dengan agak berjaya untuk menguruskan aliran data dalam aplikasi. Rajah 8-5 menunjukkan aliran data semasa melakukan ini.
Mari lihat projek ini dan bayangkan seseorang telah log masuk ke kedai buku anda dan memesan tiga buku. Lapisan pembentangan menguruskan keadaan troli beli-belah. Pelanggan bersedia untuk membuat pesanan dan telah menyediakan semua data yang diperlukan. Dia memilih untuk menghantar pesanan. Halaman web mengubah semua data menjadi Set Data yang mengandungi dua Jadual Data, satu untuk pesanan dan satu untuk pesanan; memasukkan DataRow untuk pesanan; dan memasukkan tiga DataRows untuk baris pesanan. Halaman web kemudian memaparkan data ini kembali kepada pengguna sekali lagi, mengikat kawalan data terhadap Set Data dan bertanya Adakah anda pasti? Pengguna mengesahkan permintaan dan ia diserahkan ke lapisan logik aplikasi. Lapisan logik aplikasi menyemak Set Data untuk melihat sama ada semua medan yang diperlukan mempunyai nilai dan melakukan semakan untuk melihat sama ada pengguna mempunyai lebih daripada 1000 US$. 00 pada bil tertunggak. Jika semuanya berjalan lancar, Set Data dihantar ke lapisan akses data, yang bersambung ke pangkalan data dan menjana penyata sisipan daripada maklumat Set Data.
Menggunakan Set Data dengan cara ini ialah cara yang cepat dan cekap untuk membina aplikasi dan menggunakan kuasa Pustaka Kelas Rangka Kerja dan keupayaan ASP.NET untuk mengikat data kepada pelbagai kawalan seperti GridView terhadap Set Data. Daripada menggunakan objek DataSet mudah, anda boleh menggunakan objek DataSet Taip dan meningkatkan pengalaman pengekodan dengan melaksanakan kod dalam lapisan pembentangan serta lapisan logik aplikasi. Kelebihan pendekatan ini juga merupakan kelemahan pendekatan. Perubahan kecil pada model data tidak semestinya menyebabkan banyak kaedah perlu menukar tandatangan mereka. Jadi dari segi penyelenggaraan, ini berfungsi dengan baik. Jika anda ingat bahawa lapisan pembentangan tidak semestinya antara muka pengguna, ia juga boleh menjadi perkhidmatan web. Dan jika anda mengubah suai definisi Set Data, mungkin kerana anda menamakan semula medan dalam pangkalan data, maka anda mengubah suai kontrak yang dilanggan oleh perkhidmatan web itu. Seperti yang anda boleh bayangkan, ini boleh membawa kepada beberapa isu penting. Senario ini berfungsi dengan baik jika lapisan pembentangan hanyalah antara muka pengguna, tetapi untuk antara muka kepada sistem atau komponen luaran, anda perlu menyembunyikan kerja dalaman aplikasi anda dan mengubah data menjadi sesuatu selain daripada klon langsung model data anda dan anda akan mahu mencipta Objek Pemindahan Data (DTO).
Aliran data menggunakan pemetaan hubungan objek
Aliran data menggunakan ADO.NET ialah pendekatan yang sangat mengutamakan data untuk mengurus aliran data. Data dan logik adalah diskret. Akhir spektrum yang lain mengambil pendekatan yang lebih berorientasikan objek. Di sini, kelas dicipta untuk mengumpulkan data dan tingkah laku. Matlamatnya adalah untuk mentakrifkan kelas yang meniru data dan gelagat yang terdapat dalam domain perniagaan yang mana aplikasi itu dicipta. Hasilnya sering dirujuk sebagai objek perniagaan. Pengumpulan objek perniagaan yang membentuk aplikasi dipanggil model domain. Sesetengah pembangun mendakwa bahawa model domain kaya adalah lebih baik untuk mereka bentuk logik yang lebih kompleks. Sukar untuk membuktikan atau menyangkal kenyataan sedemikian. Hanya tahu bahawa anda mempunyai pilihan dan terpulang kepada anda untuk membuatnya.
Rajah 8-6 menunjukkan aliran data yang serupa dengan Rajah 8-5 , kecuali sekarang anda telah menambah lapisan pemetaan hubungan objek dan menggantikan objek DataSet dengan pembawa data yang berbeza.
Sekarang lakukan langkah demi langkah yang sama seperti sebelumnya; bayangkan seseorang menyambung ke kedai buku anda dan memesan tiga buku. Lapisan pembentangan menguruskan keadaan troli beli-belah. Pelanggan bersedia untuk membuat pesanan dan telah menyediakan semua data yang diperlukan. Dia memilih untuk menghantar pesanan. Halaman web menukar semua data menjadi DTO, menyimpan data untuk satu pesanan dan dengan tiga baris pesanan, mencipta objek mengikut keperluan. Halaman web memaparkan data ini kembali kepada pengguna sekali lagi, mengikat data mengawal DTO menggunakan ObjectDataSource dalam ASP.NET 2.0 dan bertanya Adakah anda pasti? Pengguna mengesahkan pilihan dan DTO diserahkan ke lapisan logik aplikasi. Lapisan logik aplikasi mengubah DTO menjadi objek perniagaan jenis Pesanan dengan harta yang mengandungi tiga objek OrderLine. Kaedah Pesanan. Validate() dipanggil untuk mengesahkan pesanan dan mengesahkan bahawa semua medan yang diperlukan mempunyai nilai, dan semakan dibuat untuk mengenal pasti sama ada pengguna mempunyai lebih daripada R$ 1,000.00 dalam slip belum selesai. Untuk melakukan ini, pesanan akan memanggil Order.Customer.GetOutstandingBills(). Jika semuanya baik, kaedah Order.Save() dipanggil. Permintaan akan melalui lapisan pemetaan hubungan objek, di mana permintaan dan baris permintaan dipetakan ke DataTable dalam DataSet, dan DataSet dihantar ke lapisan akses data, yang bersambung ke pangkalan data dan menjana penyata sisipan daripada maklumat dalam Set Data. Sudah tentu, terdapat banyak cara pemetaan hubungan objek boleh berlaku, tetapi tidak semuanya akan menyertakan transformasi kepada Set Data. Sesetengah akan mencipta kenyataan sisipan secara langsung tetapi masih menggunakan lapisan akses data untuk melaksanakan kenyataan tersebut.
Seperti yang anda lihat, beberapa transformasi berlaku. Penggunaan DTO adalah perlu kerana objek perniagaan melaksanakan tingkah laku dan tingkah laku tertakluk kepada perubahan. Untuk meminimumkan kesan perubahan ini pada lapisan pembentangan, anda perlu mengubah data daripada objek perniagaan dan menjadi objek pemindahan data. Di Java, objek pemindahan data sering dirujuk sebagai objek nilai.
Kelebihan besar bekerja dengan objek perniagaan ialah ia sangat membantu untuk mengatur kod anda. Jika anda melihat kembali sekeping logik yang kompleks, ia biasanya sangat mudah dibaca kerana terdapat sangat sedikit kod paip. Kelemahannya ialah kebanyakan stor data masih berkaitan dan memetakan objek perniagaan kepada data hubungan boleh menjadi agak rumit.
perkhidmatan berasaskan skema
Anda baru sahaja melihat dua perkara yang bertentangan dalam hal mengurus aliran data. Banyak variasi mungkin. Yang biasa ialah varian yang mana set data digunakan sebagai pembawa data asas UI untuk menyimpan data, tetapi skema berasingan (DTO) digunakan untuk perkhidmatan web yang dipanggil daripada sistem lain. Lapisan aplikasi mengubah data hubungan menjadi skema yang telah ditetapkan. Kelebihan utama ini ialah mana-mana aplikasi yang merujuk perkhidmatan tidak bergantung pada sebarang jenis pelaksanaan dalaman komponen. Ini membolehkan lebih fleksibiliti dalam versi, keserasian ke belakang antara muka dan keupayaan untuk menukar pelaksanaan komponen tanpa mengubah antara muka perkhidmatan.
Sudah tentu, anda boleh menggunakan objek perniagaan dalam aplikasi web dan memintas transformasi DTO, tetapi ini biasanya hanya berfungsi dengan baik jika logik aplikasi dilaksanakan bersama-sama dengan aplikasi web. Ingat bahawa untuk memanggil Order.Save() anda memerlukan sambungan pangkalan data. Sama ada ini wajar terpulang kepada anda dan mungkin pengarah keselamatan anda.