Reputation: 31
I am new to the programming and i have some doubts about programming in c# wpf. Until now i used a programming without using patterns(mvvm, mvm, mvc etc). Based on some research i did on internet i've noticed that is better if i use different model pattern views. Until now i used some of these code for example:
SqlConnection con = new SqlConnection("Server = localhost;Database = Bilanc; Integrated Security = true");
SqlCommand cmd = new SqlCommand("Product", con); // Using a Store Procedure.
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.AddWithValue("Barcode", txtcode.Text);
dtg.ItemsSource = dataTable.DefaultView;//Set th
con.Open();//Open the SQL connection
SqlDataReader reader = cmd.ExecuteReader();//Create a SqlDataReader
while (reader.Read())//For each row that the SQL query returns do
{
DataRow dr = dataTable.NewRow();//Create new DataRow to populate the DataTable (which is currently binded to the DataGrid)
dr[0] = reader[0];//Fill DataTable column 0 current row (Product) with reader[0] (Product from sql)
dr[1] = reader[1];
dr[2] = reader[2];
dr[3] = reader[3];
dr[4] = reader[4];
dataTable.Rows.Add(dr);//Add the new created DataRow to the DataTable
txtkodi.Text = "";
object sumObject;
sumObject = dataTable.Compute("Sum(Total)", "");
txttot.Text = sumObject.ToString();
}
This is a part of code i used. Could someone of you explain how better is (mvvm, mvc) to use to improve or make better the coding. I am learning about programming and i need also to learn about these models.
I am asking because a developer told me that:Why are you working with a DataTable object as your model? Hasn't your instructor taught you about the MVVM pattern?( i had the same code , and he said these to me
Upvotes: 1
Views: 295
Reputation: 12276
Your code is tightly coupled. You have dependencies on view controls there like textboxes, datagrid or whatever dtg is. Which is fine if you're writing some little piece of code for an assignment. It's a problem for commercial code because it will be fragile and inflexible. The greatest cost in commercial software is often in maintenance. Maintaining tightly coupled code is way harder and costs more. If you sticking everything together in one chunk of code like that then when you have numerous fields and business rules and the like then your 20 lines of code ends up as 2000 lines of code. You avoid that by breaking code up into small pieces in different layers and methods. You make it more robust and flexible by reducing coupling so each piece doesn't need to know details of the others. By reducing coupling you also enable automated testing. In fact this is one reason commercial teams use MVVM - your code is in viewmodels which can easily be instantiated and tested without any view. Dependencies on data layer or model are designed such that they can be switched out to mocks/fakes for automated tests.
I suggest you read up on both mvvm and orm. As has been mentioned, it's relatively rare to see ado code nowadays and most teams will use an ORM since it's quicker to code and you write type safe code that the compiler checks.
Entity framework is very popular for desktop apps like wpf. Another one to consider is a "micro" orm like Dapper. There are trade offs with using either - EF has huge functionality and can also have significant overhead. Particularly if you don't turn off change tracking. Dapper is very lightweight but you're left to write some stuff yourself.
Once you have read up on mvvm and at least a bit on EF.
This is one way to approach crud: https://gallery.technet.microsoft.com/scriptcenter/WPF-Entity-Framework-MVVM-78cdc204
Upvotes: 1