Arsitektur Terbaik untuk Aplikasi ASP.NET WebForms


10

Saya telah menulis portal ASP.NET WebForms untuk klien. Proyek ini telah berevolusi daripada direncanakan dan terstruktur dengan baik sejak awal. Akibatnya, semua kode dihancurkan bersama dalam proyek yang sama dan tanpa lapisan. Klien sekarang senang dengan fungsionalitasnya, jadi saya ingin memperbaiki kode sehingga saya akan percaya diri untuk merilis proyek. Karena tampaknya ada banyak cara berbeda untuk mendesain arsitektur, saya ingin beberapa pendapat tentang pendekatan terbaik untuk diambil.

KEGUNAAN

Portal ini memungkinkan administrator untuk mengkonfigurasi template HTML. "Mitra" terkait lainnya akan dapat menampilkan templat ini dengan menambahkan kode IFrame ke situs mereka. Dalam templat ini, pelanggan dapat mendaftar dan membeli produk. API telah diimplementasikan menggunakan WCF yang memungkinkan perusahaan eksternal untuk berinteraksi dengan sistem juga. Bagian Admin memungkinkan Administrator untuk mengkonfigurasi berbagai fungsi dan melihat laporan untuk setiap mitra. Sistem mengirimkan faktur dan pemberitahuan email kepada pelanggan.

ARSITEKTUR SAAT INI

Saat ini menggunakan EF4 untuk membaca / menulis ke database. Objek EF digunakan langsung dalam file aspx. Ini telah memfasilitasi pengembangan yang cepat sementara saya telah menulis situs tetapi mungkin tidak dapat diterima untuk tetap seperti itu karena erat dengan db dengan UI. Logika bisnis khusus telah ditambahkan ke kelas parsial dari objek EF.

PERTANYAAN

Tujuan dari refactoring adalah untuk membuat situs scalable, mudah dirawat dan aman.

  1. Arsitektur seperti apa yang terbaik untuk ini? Tolong jelaskan apa yang seharusnya ada di setiap layer, apakah saya harus menggunakan pola DTO / POCO / Rekaman Aktif dll.

  2. Apakah ada cara yang kuat untuk menghasilkan-DTO / BO secara otomatis sehingga peningkatan di masa depan akan mudah diterapkan meskipun ada lapisan tambahan?

  3. Apakah akan bermanfaat untuk mengubah proyek dari WebForms ke MVC?


1
Lepaskan lebih awal, sering lepaskan. Saya menyarankan bahwa klien Anda mungkin tidak terlalu peduli jika Anda tidak memiliki masalah bisnis nyata untuk disajikan (misalnya, itu tidak aman). Mungkin Anda harus membersihkan sedikit (pastikan itu portabel), dan lepaskan, lalu ambil ini sebagai inisiatif jangka panjang - untuk berubah menjadi MVC atau serupa.
gahooa

2
Jangan ubah teknologi proyek kerja Anda menjadi teknologi xyz baru hanya karena teknologi itu ada, khususnya jika proyek Anda berfungsi dengan baik apa adanya. Jika berhasil jangan merusaknya. Bisnis tidak peduli dengan kode tersebut. Fungsionalitas adalah yang terpenting di akhir hari.
NoChance

ok itu benar, namun kekhawatiran saya adalah, setelah dirilis akan lebih sulit untuk refactor karena risiko melanggar ketika taruhannya jauh lebih tinggi. Jadi kita akan terjebak dengan kode yang tidak dapat dirawat dan lebih sulit untuk di-debug dll. Saya tergoda untuk belajar / mengonversi ke MVP tetapi itu terlihat seperti terlalu banyak pekerjaan. Sejauh ini saya baru saja mengonversinya menjadi DAL, Domain, lapisan UI yang terasa lebih terorganisir namun masih memungkinkan RAD yang tak terelakkan yang akan diperlukan saat proyek masih muda. Suatu hari jika perlu saya dapat memperluas ke MVP atau MVC saya kira - setelah saya punya cukup waktu untuk mempelajari cara kerjanya.
tumpukan manusia

Yang terasa masih berantakan adalah: 1) Objek EF di UI (kode di belakang file di lapisan UI)
stack man

(2) Logika bisnis dalam objek EF yang diperluas yang harus masuk dalam lapisan DAL (tidak menyadari kelas parsial harus berada dalam rakitan yang sama) (3) Logika bisnis dalam file aspx.cs di lapisan UI. Namun, sepertinya sering ada kompromi dalam hal arsitektur tetapi ini jelas merupakan langkah maju. Saya merasa bahwa ini dapat diterima untuk rilis pertama dan seiring berjalannya waktu kita dapat menilai kembali pendekatan kita. Terima kasih atas bantuan Anda semuanya. Adalah baik untuk mendapatkan sedikit arah karena area ini sangat subyektif.
tumpukan manusia

Jawaban:


5

Pola ASP.NET MVP adalah arsitektur terbaik untuk aplikasi webforms ASP.NET jangka panjang . Ini mulai bermain dengan konsep "pemisahan keprihatinan", yang merupakan tren di balik pola MV *.

Pertanyaan tentang Mengapa menggunakannya? - dibahas secara rinci dalam posting ini - ASP.NET MVP


Masalahnya adalah, itu akan membutuhkan banyak pekerjaan untuk refactor proyek ke MVC ... jika saya menyimpannya sebagai aplikasi WebForms dengan Domain Layer (kode pertama, POCO), Data Access Layer (hanya konteks db) dan UI, akankah Anda menganggap ini desain yang dapat diterima untuk produksi? Di kemudian hari kita bisa mempertimbangkan untuk mengubahnya menjadi MVC.
tumpukan manusia

Yah, itu adalah pola MVP (model-view-presenter) dan BUKAN MVC (model-view-controller).
Yusubov

1
oh maaf - saya salah baca. Terima kasih - saya akan membaca tentang desain MVP.
tumpukan manusia

tidak masalah, saya harap Anda akan menemukan apa yang Anda cari :)
Yusubov

Tampaknya mengonversi ke MVP juga akan menjadi perubahan besar. Klien ingin segera merilis, jadi apakah menurut Anda arsitektur yang disebutkan di atas DAL / DA / UI (walaupun tidak se-ideal MVP) akan dapat diterima untuk jenis aplikasi ini? Kemudian setelah rilis kita bisa melihat pindah ke MVP di v2.
tumpukan manusia

1
  1. Gunakan pola MVP untuk memisahkan dan logika dan UI, jadi di masa depan Anda dapat pindah ke teknologi UI yang berbeda menggunakan kembali logika yang ada
  2. Gunakan pola repositori antara BL dan DAL sehingga Anda dapat mengubah RDBS apa pun menggunakan kembali logika bisnis
  3. bawa layer terpisah (Dll) untuk BO dan DAL yang meminimalkan perawatan.

Tidak yakin mengapa ada orang yang memilih pertanyaan ini. Sejujurnya, ini adalah jawaban yang paling ringkas. +1
Greg Burghardt

0

Seperti yang disebutkan ElYusubov, pola MVP bisa menjadi besar.

Konsep kuncinya adalah menghapus sebagian besar atau semua logika Anda dari kode di belakang. Logika tidak harus terikat ke halaman. Bagaimana jika Anda perlu menggunakan kembali logika dari satu halaman di halaman lain? Anda akan tergoda untuk menyalin dan menempel. Jika Anda melakukan ini maka proyek Anda akan dapat dipertahankan.

Jadi, sebagai permulaan mulailah refactoring logika Anda dari kode-belakang dan letakkan di lapisan bisnis. Jika Anda berhasil mendapatkan semua logika dari kode-belakang maka Anda dapat mengimplementasikan antarmuka yang diperlukan untuk menjadi MVP sejati.

Pastikan juga akses data Anda terpisah dari logika bisnis Anda. Buat layer data dan mulai refactoring di ujung itu juga. Karena Anda menggunakan EF4, ini bukan masalah karena EF harus memisahkannya. Anda harus dapat dengan mudah memindahkan semua file EF ke proyek lain dan cukup menambahkan referensi ke proyek yang membutuhkannya. Manfaat tambahan adalah, Anda mungkin perlu referensi model data Anda di proyek lain.

Untuk menghindari kewalahan, lakukan refactor sedikit demi sedikit. Setiap kali Anda menyentuh sepotong kode, pertimbangkan untuk mengembalikan kode di sekitarnya. Jika Anda melakukan ini, seiring waktu proyek Anda dapat menjadi lebih dapat dipertahankan.

Edit

Anda bertanya tentang memiliki kode di belakang mewarisi kelas logika bisnis. Ini tidak dapat dilakukan karena kode di belakang halaman "is-a". C # tidak memungkinkan pewarisan berganda, sehingga kelas kode-belakang tidak bisa berupa halaman dan objek kustom. Anda perlu memisahkan logika secara konseptual. Mungkin saja kode di belakang kode Anda melakukan banyak hal berbeda. Kelas harus melakukan satu hal dan satu hal saja. Coba dan pikirkan bagaimana Anda secara konseptual dapat menarik fungsionalitas yang ada. Misalnya, katakanlah Anda memiliki halaman pendaftaran dan Anda mengumpulkan informasi pengguna. Anda mungkin memiliki tombol yang disebut register dan acara klik yang terkait dengan tombol itu. Jika demikian, Anda menyimpan informasi pengguna dan melakukan pemrosesan apa pun yang Anda butuhkan. Anda bisa membuat objek Pendaftaran untuk menangani semua logika itu.

Ini bukan hanya pemisahan yang lebih bersih tetapi juga bisa menjadi cara untuk mendokumentasikan kode Anda sendiri. Ketika seseorang membaca kode Anda, mereka melihat Anda memanggil objek Registrasi sehingga Anda tahu persis apa yang terjadi.

Jika Anda ingin secara ketat mengikuti pola MVP, alih-alih meneruskan parameter ke objek Registrasi, kode-belakang akan mengimplementasikan antarmuka. Implementasi antarmuka pada dasarnya akan memetakan semua objek tampilan (bidang teks dll) ke antarmuka. mis. public string FirstName {get {return txtFirstName.Text; }}

Setelah selesai, Anda bisa melewati halaman ke objek Regisration

Registrasi.Pendaftar Pengguna (ini);

Dan metode RegisterUser ini akan menggunakan antarmuka sebagai parameter

public bool RegisterUser (pengguna IUser) {user.FirstName ...}

antarmuka publik IUser {public string FirstName; }

Jika MVP ini terdengar membingungkan, fokus saja pada refactoring dan ketahuilah semua ini untuk memaksimalkan penggunaan kembali kode. Tidak ada sejak mengulangi diri Anda sendiri. Itu kepala sekolah KERING .


Terima kasih atas tips bermanfaat Anda. Ya, saya pasti sedikit kewalahan dengan ini. Tampaknya bagi saya bahwa MVC akan menjadi pola terbaik untuk digunakan tetapi MVP akan lebih mudah untuk dicapai dan akan menjadi pola terbaik berikutnya. Saya selalu menggunakan kode di belakang file sehingga selalu menggaruk-garuk kepala saya tentang bagaimana logika bisnis dapat dipisahkan dari presentasi ... jadi saya harus bisa memindahkan file .aspx.cs saya ke lapisan domain dan memiliki pernyataan pewarisan di aspx ? Tentu saja berakhir dengan 3 lapisan akan membuat saya merasa nyaman dengan merilis versi 1 - maka saya dapat memperbaikinya dari sana.
tumpukan manusia

Saya akan menanggapi komentar Anda dalam jawaban saya. Jangan ragu untuk memperbaiki jawaban saya jika Anda menemukannya berguna
coder
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.