Data Access in the User Interface
I get this question a lot. I definitely understand the need that drives it as well. You are just learning a new user interface and you want to see how it would work in a real world environment. Real world environments are almost always about data so seeing how to perform CRUD operations (Create, Read, Update, and Delete) seems like a good idea.
Here is the problem with this mindset: user interfaces should not be directly doing CRUD operations. Instead, they should be talking to class libraries that handle the CRUD operations. I won’t go into all the details of why this is true, but the basics are that when you disconnect the user interface from the CRUD, it is much easier to replace the user interface or the data access layer without major project disruption. I demonstrate setting a project up like this in my C# Application from Start to Finish course. Baked right into the course is the idea that we might want to use a different data access layer at the flip of a switch. It also demonstrates how good separation also allows you to change out your user interface easily by doing just that. I have an add-on course that replaces the WinForm UI with an ASP.NET MVC UI and a WPF UI with MVVM.
On the other hand, demonstrating how a user interface would display data and how it would capture the modifications to data is very important. If you watch my intro videos for WPF, ASP.NET MVC, and WebAPI, you will see that I demostrate how to show and get information. Those are the pieces you need to hook up your own data access layer.