Before talking about model, you can read about what is the "model" thing in MVC design pattern explanation. The simple explanation about model (my interpretation, don't use it in exams) is something which represent the structure of data, and possess the logic to get and/or modify the data.
Usually, model's logic can be integrated with the controller (or view model), and the structure itself can be represented using data sets (for database, or xml documents for xml). So in most cases, developers really can ignore model and integrated it with the controller itself. So why is it needed to separate the model?
If we said about small application, it will be okay to ignore model, and integrate it with the controller at all. But what if we talk about large applications? It will be hell if we use data sets or xml documents itself. A slight change with the data structure, and you must search for every controller which used that data. Yeah I already said every controller, and if the application has so many controller, it will be a pain.
Not only that, in additional model can hold some logic that bound to data, so every controller used the data can have same behavior of the logic. Let's say that a request has some mechanics like discounts or so. Instead of put the logic in controller or database, we can put it in model. So in summary, I will say that the model is quite a handy tool for data management.
The Popular MVC Design Pattern
If you need reason(s) why the desin pattern are needed in software programming, you can read mw previous post.
Honestly, at the first time I learnt this design pattern, I find it was a bit confusing. Moreover, I find it useless to separate model with the controller, even I can immediaetly find the importance to separate the view an controller. However after try to create a php project using codeigniter framework, I find the requirement are somewhat important.
Before talking further about MVC, let me tell you the basis of MVC. The view, to be simple are the user interface. It is related to everything what user sees, what user input, what user choose and logics of the UI to communicate with controller (in this case, form tag and ajax call are considered a view.
Controller on the contrary, receiving input from view, processing it with logics (if else, loop, mathematical logics, etc), getting the data from model, sending the data to model, and even choose what view will be displayed after all the process done.
Model is the object that you use in controller. Model which data will be displayed in view, which hold the logic to modify the data in storage (can be database, xml, pure text files, encoded file, etc), getting the data from storage, and hold the structure of data.
From that explanation, we can see that it is obvious to separate view with controller, in order to separate business logic with UI logic. But why is it needed for model to be separated with the controller, instead just handle the model (get and modify the data) in controller? We can get the explanation in this post.
Honestly, at the first time I learnt this design pattern, I find it was a bit confusing. Moreover, I find it useless to separate model with the controller, even I can immediaetly find the importance to separate the view an controller. However after try to create a php project using codeigniter framework, I find the requirement are somewhat important.
Before talking further about MVC, let me tell you the basis of MVC. The view, to be simple are the user interface. It is related to everything what user sees, what user input, what user choose and logics of the UI to communicate with controller (in this case, form tag and ajax call are considered a view.
Controller on the contrary, receiving input from view, processing it with logics (if else, loop, mathematical logics, etc), getting the data from model, sending the data to model, and even choose what view will be displayed after all the process done.
Model is the object that you use in controller. Model which data will be displayed in view, which hold the logic to modify the data in storage (can be database, xml, pure text files, encoded file, etc), getting the data from storage, and hold the structure of data.
From that explanation, we can see that it is obvious to separate view with controller, in order to separate business logic with UI logic. But why is it needed for model to be separated with the controller, instead just handle the model (get and modify the data) in controller? We can get the explanation in this post.
Design Pattern, How Important is it
Design pattern is usually be used in software application programming. There are some design pattern which is used widely by enterprise, or insividual programmer. But how important is this design pattern 'thing'?
The main purpose of design pattern is to separate the application interface (UI) with the business logic. Why is it needed to do such thing?
In my latest job, there was a project which need to be handed over to me. The project are using Asp.Net webform. The structure of the project are using event-driven structure, as the basis of Asp.Net webform design.
The business logic (lets say that as the logic to submit a request, validate the form or updating the request) are being done in code behind of aspx.cs form. To be worse, the business logic sometimes handled in asmx webservice and being triggered by jquery ajax, making it harder for me to decrypt it.
Well, the pain did not stop there. The design are making it harder to be modified. A little modification can cause errors in other places, and more effort are needed to unify the change in other places as well. This is, are contrary with principal of object oriented, which is encapsulation and reuseability.
So how can a design pattern be used to solve these usually founded problems? I will try to describe it in my future posts.
The main purpose of design pattern is to separate the application interface (UI) with the business logic. Why is it needed to do such thing?
In my latest job, there was a project which need to be handed over to me. The project are using Asp.Net webform. The structure of the project are using event-driven structure, as the basis of Asp.Net webform design.
The business logic (lets say that as the logic to submit a request, validate the form or updating the request) are being done in code behind of aspx.cs form. To be worse, the business logic sometimes handled in asmx webservice and being triggered by jquery ajax, making it harder for me to decrypt it.
Well, the pain did not stop there. The design are making it harder to be modified. A little modification can cause errors in other places, and more effort are needed to unify the change in other places as well. This is, are contrary with principal of object oriented, which is encapsulation and reuseability.
So how can a design pattern be used to solve these usually founded problems? I will try to describe it in my future posts.
C# Stored Procedures vs Linq
Dalam dot net programming, banyak cara bagi developer untuk melakukan hubungan dengan database dan mengaksesnya. Secara umum ada 2 cara yang umum digunakan yaitu menggunakan DataSet+SqlDataAdapter atau Linq.
Secara garis besar, kita dapat menggambarkan keuntungan Linq dibanding data adapter:
Secara garis besar, kita dapat menggambarkan keuntungan Linq dibanding data adapter:
- object oriented, sehingga tipe data yang diakses sudah terkonversi menjadi data type dot net. Hal ini membuat penggunaan tipe data yang lebih aman
- Linq memiliki query optimizer sendiri sehingga query dasar yang digunakan developer sudah diimprove secara otomatis
- relasi table dapat dilakukan secara obect-oriented sehingga lebih mudah digunakan saat development
- struktur objek Linq sangat bergantung pada struktur database, sehingga perubahan sekecil apapun akan memerlukan penangan dari sisi applikasi atau applikasi berpotensi break. Sementara mengubah stored procedures tidak memerlukan perubahaan dari sisi applikasi.
- sulit untuk menelusuri query-query yang digunakan (terutama yang kompleks). Tujuan dari penelusuran tersebut seperti saat debugging atau indexing
- stored procedures dapat digunakan untuk query yang simple hingga yang query kompleks seperti summarize atau pagination
C# Winforms vs WPF
Banyak sekali modul-modul applikasi yang dapat dibangun dan dipergunakan dengan menggunakan .Net C# Winforms. Winforms sendiri juga sudah merupakan framework yang bagus, sudah full-oop, event-driven dan stable. Namun mengapa Windows memutuskan untuk mengeluarkan framework yang lain, yaitu WPF, sebagai framework desktop lain di samping winforms? Berikut adalah perbedaan antara WPF dan Winforms.
- Winforms sangat mendukung architecture pattern MVC (model-view-controller), sementara WPF lebih mendukung menggunakan architecture pattern MVVM (model-view-viewmodel)
- Dalam arsitekturnya, Winforms adalah event-driven sementara WPF lebih mendukung binding
- Component (control) dalam WPF lebih customizable dibanding Winforms
- Struktur penulisan WPF adalah hampir sama dengan Silverlight, modul mirip flash yang dapat di-run dari browser
- Winforms menggunakan Windows API dalam men-render UI sementara WPF menggunakan directX sehingga lebih lightweight (less resource)
- Konstruksi UI winforms seluruhnya menggunakan codebehind, sementara WPF menggunakan XAML (walaupun dapat juga dilakukan dari codebehind)
- Pada WPF terdapat control "Style", yang dapat di-reuseable sehingga user tidak perlu membuat usercontrol sendiri untuk me-style kan controlnya.
C# Public Property vs Public Attribute
Well, setelah cukup lama bermain dengan C#, ada beberapa hal yang terkesan 'lucu' dalam pembelajaran. Hal tersebut adalah property vs attribute.
Dalam mendeklarasi class di C#, ada beberapa cara untuk merepresentasikan attribut, di antaranya adalah:
Dalam mendeklarasi class di C#, ada beberapa cara untuk merepresentasikan attribut, di antaranya adalah:
- Public attribute, yaitu dengan mendeklarasi attribute dengan access modifier public, sehingga mudah dapat digunakan oleh class lain
- Property, yaitu mendeklarasi public attribute dengan accessor get; dan/atau set;
- Function getter setter, cara ini digunakan umum oleh java
Try / Catch, The Double-edged Sword
Try/catch, untuk mayoritas programmer (terutama java) pasti tidak asing lagi dengan syntax tersebut. Syntax tersebut memiliki kemampuan yang hebat dan sangat membantu dalam melakukan pengembangan.
Namun, penggunaan try/catch yang tidak hati-hati dan sembarangan dapat membuat celah dalam sistem. Salah satu celah yang paling umum adalah tidak adanya error message (isi catch kosong). Celah tersebut membuat debugging menjadi susah karena exception tidak menghasilkan error box.
Jadi, apa saja yang harus diperhatikan dalam penggunaan try/catch? Berikut adalah beberapa hal yang sepengalaman saya harus diperhatikan:
1. Penanganan Exception dalam catch.
Object Exception memiliki property Message yang membawa pesan error yang terjadi. Salah satu penanganan exception yang paling mudah adalah menggunakan MessageBox (desktop app) atau Response.Write (asp). Penanganan lebih 'advanced' dapat berupa refresh data, kalkulasi autonomous, dan lainnya sesuai dengan tujuan.
2. Object Exception memiliki turunan
Object Exception memiliki turunan sesuai dengan error yang ada. Misalnya seperti FormatException pada .Net yang dihasilkan dari penggunaan format yang berbeda (misalnya ada karakter ketika parsing ke int, umumnya terjadi ketika parse). Ada juga NullReferenceException dimana program berusaha mendapatkan dan memproses variable yang bernilai null. Penanganan yang berbeda untuk tiap-tiap jenis Exception yang berbeda dapat membantu mempercepat development.
3. Pastikan tidak ada proses bersangkutan yang berjalan setelah ada Exception. Ingat, proses tetap berjalan setelah try/catch.
Misalkan anda memiliki int angka yang didapat dari parsing tbox1.Text. Anda men-'trap' proses parsing tersebut ke dalam try/catch. Kemudian angka tersebut akan digunakan untuk memasukkan data ke dalam database. Proses input data tersebut akan tetap berjalan walaupun ada Exception tanpa penanganan.
Proses yang salah:
Salah satu cara untuk menghindarinya:
Namun, penggunaan try/catch yang tidak hati-hati dan sembarangan dapat membuat celah dalam sistem. Salah satu celah yang paling umum adalah tidak adanya error message (isi catch kosong). Celah tersebut membuat debugging menjadi susah karena exception tidak menghasilkan error box.
Jadi, apa saja yang harus diperhatikan dalam penggunaan try/catch? Berikut adalah beberapa hal yang sepengalaman saya harus diperhatikan:
1. Penanganan Exception dalam catch.
Object Exception memiliki property Message yang membawa pesan error yang terjadi. Salah satu penanganan exception yang paling mudah adalah menggunakan MessageBox (desktop app) atau Response.Write (asp). Penanganan lebih 'advanced' dapat berupa refresh data, kalkulasi autonomous, dan lainnya sesuai dengan tujuan.
2. Object Exception memiliki turunan
Object Exception memiliki turunan sesuai dengan error yang ada. Misalnya seperti FormatException pada .Net yang dihasilkan dari penggunaan format yang berbeda (misalnya ada karakter ketika parsing ke int, umumnya terjadi ketika parse). Ada juga NullReferenceException dimana program berusaha mendapatkan dan memproses variable yang bernilai null. Penanganan yang berbeda untuk tiap-tiap jenis Exception yang berbeda dapat membantu mempercepat development.
3. Pastikan tidak ada proses bersangkutan yang berjalan setelah ada Exception. Ingat, proses tetap berjalan setelah try/catch.
Misalkan anda memiliki int angka yang didapat dari parsing tbox1.Text. Anda men-'trap' proses parsing tersebut ke dalam try/catch. Kemudian angka tersebut akan digunakan untuk memasukkan data ke dalam database. Proses input data tersebut akan tetap berjalan walaupun ada Exception tanpa penanganan.
Proses yang salah:
int angka=0;
try{
angka = int.Parse(tbox1.Text);
}
catch(Exception e){
//show message here
}
//insert process, nilai angka adalah 0
Salah satu cara untuk menghindarinya:
int angka=0;
try{
angka = int.Parse(tbox1.Text);
//insert process
}
catch(Exception e){
//show message here
}
Subscribe to:
Posts (Atom)