c# wpf mvvm pattern

Question

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

Your code is a SQL connection to a database, it has nothing to do with MVVM, MVC, MVP, MV* or any other design pattern for that matter. — Aydin, Mar 24 '18 at 11:39
Have a look at: https://stackoverflow.com/questions/23648832/viewmodels-in-mvc-mvvm-seperation-of-layers-best-practices/23649191#23649191 — Stefan, Mar 24 '18 at 11:45
#aydin adn. A developer said to me::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 — lex, Mar 24 '18 at 11:53
They're clueless themselves, they're talking about an ORM but they dont even know its called an ORM by sounds of things, dealing directly with SQL is a pain in the butt when you compare it to working with ORMS. What's an ORM? Think of it as a tool that allows you to avoid typing all that tedious code for every operation you want to perform and instead be able to query your database as if you were querying a list. A good starting point is Entity Framework from Microsoft for instance. MVVM is something completely unrelated to the code above, because MVVM doesn't tackle data layer issues — Aydin, Mar 24 '18 at 11:57
Don't use Stack Overflow as a learning source. You'll get autobanned from all the downvotes. Books are for answering questions like this. — , Mar 26 '18 at 16:09

Andy · Accepted Answer · 2018-03-24T14:48:23.207

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

c# wpf mvvm pattern

1 Answers1