Latest / DevQuestions with Tim Corey / 040 How Do I Do Data Access In Blazor? MVC? WPF?

Transcript

040 How Do I Do Data Access In Blazor? MVC? WPF? · DevQuestions with Tim Corey

• 0:00
  SPEAKER_00: Welcome to the Dev Questions Podcast with Tim Corey.
• 0:03
  SPEAKER_00: Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology.
• 0:12
  SPEAKER_00: If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered.
• 0:19
  SPEAKER_00: Now, here's your host, expert developer and online educator, Tim Corey.
• 0:25
  SPEAKER_01: How do I perform data access in Blazor?
• 0:28
  SPEAKER_01: How about MBC?
• 0:29
  SPEAKER_01: What about WPF?
• 0:31
  SPEAKER_01: These types of questions I get so many times.
• 0:34
  SPEAKER_01: I figured I'd answer them today's dev question episode.
• 0:38
  SPEAKER_01: There's there's a lot to cover here.
• 0:42
  SPEAKER_01: And I want to say right up front, data access should not be affected by your user interface.
• 0:50
  SPEAKER_01: I'm gonna put an asterisk there, we'll talk about what the exception to that rule is, but let me repeat that.
• 0:56
  SPEAKER_01: Data access should not be affected by our user interface.
• 1:00
  SPEAKER_01: So when you say, how do I do data access in Blazor?
• 1:04
  SPEAKER_01: the same way you did it in your console app.
• 1:07
  SPEAKER_01: How about MVC?
• 1:08
  SPEAKER_01: Yep, the same way you did it in WPF.
• 1:11
  SPEAKER_01: It's the it should be the same.
• 1:13
  SPEAKER_01: So let's talk about some of the confusion here.
• 1:17
  SPEAKER_01: Now, the very first thing you may have heard of a term called a code smell.
• 1:22
  SPEAKER_01: Now, this is a weird term in some ways, but the idea here is that when you hear about a code smell, it's not saying this is bad.
• 1:33
  SPEAKER_01: What it's saying is it might be bad.
• 1:37
  SPEAKER_01: Okay, there's a difference.
• 1:38
  SPEAKER_01: It's not saying it's kind of like a uh design pattern where, you know, yeah, it's it's a thing you could apply, but you don't have to apply, or a principle where it's even more nebulous, where you can, but you don't have to.
• 1:56
  SPEAKER_01: So not every situation is the same, but you should look at it if you're not doing it.
• 2:00
  SPEAKER_01: Okay, that's the kind of thing we're talking about.
• 2:02
  SPEAKER_01: So when you see repetition in code, that's probably the easiest design smell to identify is repetition in code, where you see the same code more than once.
• 2:15
  SPEAKER_01: That that violates dry, the principle of dry.
• 2:19
  SPEAKER_01: Well, or which is don't repeat yourself if you didn't know.
• 2:22
  SPEAKER_01: Um, good one to pay attention to.
• 2:24
  SPEAKER_01: If you're repeating yourself as a developer, that's something to look into.
• 2:28
  SPEAKER_01: Well, that's a code smell, but it doesn't mean it necessarily is wrong.
• 2:35
  SPEAKER_01: There are times when repeating yourself is the right thing to do.
• 2:39
  SPEAKER_01: So when I say this, I want you to hear what I'm saying.
• 2:44
  SPEAKER_01: The code smell is that changing your user interface for data access.
• 2:49
  SPEAKER_01: That's a code smell.
• 2:51
  SPEAKER_01: So whenever you're changing your user interface for your data access, or you're changing your data access because of your user interface, that's a code smell.
• 3:01
  SPEAKER_01: That's that's a a at least a yellow, if not a red, warning flag popping up in your application saying, look into this, because the two should not be connected in any direct way.
• 3:15
  SPEAKER_01: There should be a buffer in between.
• 3:18
  SPEAKER_01: Now, this raises the question, which may become a separate uh video slash podcast episode of its own, which is um, what are the different layers of your application?
• 3:29
  SPEAKER_01: Just define the layers.
• 3:30
  SPEAKER_01: Is it three layers, is it five layers, is it 10 layers?
• 3:34
  SPEAKER_01: There's not a there's not a clear-cut answer like you'd want.
• 3:38
  SPEAKER_01: I grew up with there's three layers, and it's a lot more negles than that.
• 3:42
  SPEAKER_01: That's a whole different story, though.
• 3:44
  SPEAKER_01: But there should be a separate layer or a separate piece for your data access versus your user interface.
• 3:52
  SPEAKER_01: There are exceptions to the rule, but in general, you want those two things separated.
• 3:58
  SPEAKER_01: Okay, so your user interface should be dealing with data, which is a list of models, or it's it's classes with data in them.
• 4:10
  SPEAKER_01: It's not, it should not be direct data access.
• 4:15
  SPEAKER_01: So when people say, okay, well, where do I put data access in MVC?
• 4:20
  SPEAKER_01: That's three layers, right?
• 4:21
  SPEAKER_01: The answer is no.
• 4:22
  SPEAKER_01: MVC is all user interface layer.
• 4:25
  SPEAKER_01: Okay, the models, the views, and the controller, those are all UI layer.
• 4:29
  SPEAKER_01: You still have your business logic layer, you still have your data access layer.
• 4:32
  SPEAKER_01: If you're doing a three-layer model, um, you still those layers beyond what's in the MVC.
• 4:38
  SPEAKER_01: The same is true for WPF.
• 4:40
  SPEAKER_01: Um, if you have like an MVVM structure, which part do you put the data access in with an MVVM structure?
• 4:48
  SPEAKER_01: You don't, because MVVM is all user interface.
• 4:52
  SPEAKER_01: Model, view, and view model, those are all UI.
• 4:55
  SPEAKER_01: Okay.
• 4:56
  SPEAKER_01: Then you still have your data access and you still have your business logic layers separate from those.
• 5:03
  SPEAKER_01: Okay, so my data access library that I use for probably 95% of my projects is a little um Dapper library that I've created to just kind of wrap some things and make it a little easier for the way I do things.
• 5:19
  SPEAKER_01: It's a pretty personal library.
• 5:20
  SPEAKER_01: It's not something I would necessarily give away.
• 5:23
  SPEAKER_01: I mean, I can, it's it's there's not a secret there.
• 5:25
  SPEAKER_01: I used it in Timco and I've used it in other places.
• 5:28
  SPEAKER_01: But um, it's just, you know, my take on Dapper and how I use it.
• 5:33
  SPEAKER_01: Well, that is all kind of self-contained, and then I put a wrapper around that for my data access so that when either my business logic or maybe even directly my my user interface asks for data, they just say, Give me employees.
• 5:52
  SPEAKER_01: That's it.
• 5:53
  SPEAKER_01: And then I give them back a list of a model, okay?
• 5:57
  SPEAKER_01: And that's it.
• 5:58
  SPEAKER_01: So they have no clue where that comes from.
• 6:01
  SPEAKER_01: Now, one of the benefits there is that later on down the road, which does not happen very often, so hear me out here.
• 6:08
  SPEAKER_01: But later on down the road, I say, you know what?
• 6:11
  SPEAKER_01: SQL's not working for me.
• 6:12
  SPEAKER_01: I want uh MongoDB.
• 6:15
  SPEAKER_01: Cool.
• 6:16
  SPEAKER_01: Your user interface shouldn't have to change at all.
• 6:19
  SPEAKER_01: Your business logic shouldn't have to change at all.
• 6:22
  SPEAKER_01: Only your data access should have to change.
• 6:26
  SPEAKER_01: Okay.
• 6:26
  SPEAKER_01: Now, again, once you get to production, once you've got your application working in production, you probably aren't going to change your data access layer.
• 6:36
  SPEAKER_01: That's a pretty big significant change.
• 6:39
  SPEAKER_01: But if you did, that would be why.
• 6:42
  SPEAKER_01: Okay, that'd be how you do it effectively is to have that separation.
• 6:46
  SPEAKER_01: If it's tied all the way into your user interface, you're throwing the whole application out.
• 6:52
  SPEAKER_01: If you have your layers separated with uh loose coupling, then you can replace the user interface without replacing your business logic or your data access logic.
• 7:03
  SPEAKER_01: Or you can replace your data access without replacing or changing your business logic or your user interface.
• 7:11
  SPEAKER_01: Okay, so in the Timco Retail Manager series, we've really broken it up quite a bit.
• 7:16
  SPEAKER_01: And the data access is a class library off of the API project.
• 7:24
  SPEAKER_01: The API, just so we're clear here, is the user interface.
• 7:29
  SPEAKER_01: Okay, just want to point that out there.
• 7:31
  SPEAKER_01: The API is the user interface layer.
• 7:35
  SPEAKER_01: Now, the user is often a computer, not a or a program, not a person.
• 7:43
  SPEAKER_01: But that's still that's still a user.
• 7:45
  SPEAKER_01: It's not a GUI, it's not a graphical user interface, it's just a user interface, but it is a UI.
• 7:52
  SPEAKER_01: Then we have our business logic, and then we have our data access.
• 7:59
  SPEAKER_01: With that, then the API becomes kind of like our data access for our WPF project, which we're adding a Blazor Web Assembly user interface on top of our project or as an additional UI.
• 8:15
  SPEAKER_01: Well, that's connecting to the same API.
• 8:18
  SPEAKER_01: So now I have two different, very different user interfaces: one WPF desktop app and one Blazor WebAssembly uh web application.
• 8:29
  SPEAKER_01: Both of them will talk through the API to my data access eventually through a number of steps.
• 8:36
  SPEAKER_01: But by taking those steps, it allows us to have that disconnected nature where I can pull out and change one piece.
• 8:45
  SPEAKER_01: If, because the Timco retail manager isn't in production yet, if I say, you know what, let's learn something new, we could replace our SQL Server with Cosmos DB, and it would take us one episode.
• 9:03
  SPEAKER_01: That's it.
• 9:04
  SPEAKER_01: Okay.
• 9:05
  SPEAKER_01: In one video, we could replace that SQL Server with a um a Cosmos DB database instead, and it would just work.
• 9:14
  SPEAKER_01: Okay, because the user or the data access layer, the data access code, let's call it code.
• 9:21
  SPEAKER_01: Forget layers, just call it code.
• 9:23
  SPEAKER_01: That code is not connected tightly to anything else, it's loosely connected so that we would just have to change a little bit of code and then everything else would just work because all it's expecting is do we have a model with data in it?
• 9:43
  SPEAKER_01: Well, yes, we do.
• 9:44
  SPEAKER_01: Cool.
• 9:45
  SPEAKER_01: That's all I care about.
• 9:46
  SPEAKER_01: Okay.
• 9:47
  SPEAKER_01: So I want you to think about this.
• 9:49
  SPEAKER_01: When I I taught a video, actually, two videos on my YouTube channel.
• 9:55
  SPEAKER_01: One is called um connecting C sharp to SQL the Easy Way, I believe.
• 10:01
  SPEAKER_01: And the other is called Advanced Dapper.
• 10:04
  SPEAKER_01: Those two videos, I believe I did both of them in console.
• 10:10
  SPEAKER_01: I'm pretty sure I did both of them as console applications.
• 10:12
  SPEAKER_01: Um you can go and check and find out.
• 10:15
  SPEAKER_01: But that teaches Dapper, and that's my favorite data access for SQL.
• 10:20
  SPEAKER_01: That's my favorite uh data access layer tool for SQL.
• 10:24
  SPEAKER_01: Well, you can take that code and use it in MVC, in RazorPages application, in API, in WPF, in Winforms, in a console, in a Blazor Server application.
• 10:40
  SPEAKER_01: You can use the same code in all of those and nothing will have to change.
• 10:46
  SPEAKER_01: Okay?
• 10:47
  SPEAKER_01: So when you think about different pieces of C sharp, I want to make sure you disconnect anything that's not user interface specific from the user interface.
• 11:02
  SPEAKER_01: It'll make your life a whole lot easier when it comes to doing research.
• 11:06
  SPEAKER_01: So when you're learning about delegates, you don't have to look for delegates in MVC, delegates in Razor Pages, delegates in WPF.
• 11:15
  SPEAKER_01: No.
• 11:15
  SPEAKER_01: Learn about delegates.
• 11:17
  SPEAKER_01: Who cares what the UI is?
• 11:19
  SPEAKER_01: Because once you learn about delegates, they'll work the same way in the other projects.
• 11:23
  SPEAKER_01: Okay?
• 11:24
  SPEAKER_01: So you can do that with most things in C sharp.
• 11:28
  SPEAKER_01: It's only the user interface specific things that are unique to that user interface.
• 11:35
  SPEAKER_01: So you're talking about uh learning about um blazer components.
• 11:41
  SPEAKER_01: Well, yeah, they won't work in API.
• 11:43
  SPEAKER_01: Okay, they won't work in WPF yet.
• 11:47
  SPEAKER_01: We can probably get that to work, but um they don't necessarily work in those other things because that's a user interface specific component.
• 11:56
  SPEAKER_01: But for most things in C sharp, they're not user interface specific.
• 12:02
  SPEAKER_01: And that's something to pay attention to is what's the difference here?
• 12:07
  SPEAKER_01: Is this a UI-specific thing, or is it just a general, I'm learning about this topic in C sharp?
• 12:14
  SPEAKER_01: Okay, so there's a lot of stuff, probably 90% of the stuff you're gonna learn, is going to be non-user interface specific.
• 12:22
  SPEAKER_01: Don't try and learn just your given user interface for that topic.
• 12:30
  SPEAKER_01: It doesn't matter which type you learn, learn about it in general and then figure out how to put it into your user interface.
• 12:36
  SPEAKER_01: Now, I did say there was a one asterisk, there was one exception, and that is the brand new as of uh May of 2020.
• 12:46
  SPEAKER_01: The brand new Blazor WebAssembly project type.
• 12:51
  SPEAKER_01: This is a different animal.
• 12:53
  SPEAKER_01: And the reason why is because everything works client side.
• 12:57
  SPEAKER_01: Okay, everything, all your C sharp code is visible to the user.
• 13:01
  SPEAKER_01: It all gets downloaded to the user machine and run there.
• 13:05
  SPEAKER_01: So that's different from every other ASPNET core type, including Blazor Server.
• 13:12
  SPEAKER_01: Because all of those, your code lives in a server and it gets compiled on the server, and code never goes to the client.
• 13:20
  SPEAKER_01: So even in Blazor Server, if you want to talk to SQL Server, it's the same way as if you're talking uh via WPF or console or MVC.
• 13:31
  SPEAKER_01: Okay, but with Blazor WebAssembly, you can't talk directly to SQL because you'd have to have the credentials on the client.
• 13:42
  SPEAKER_01: That's not a good thing.
• 13:44
  SPEAKER_01: And that's why Blazor WebAssembly, we use an API.
• 13:48
  SPEAKER_01: If you want to talk to SQL, you can do it through an API.
• 13:52
  SPEAKER_01: And then guess what?
• 13:54
  SPEAKER_01: That data access is the exact same in that API as it is in a console app.
• 13:59
  SPEAKER_01: So that one exception, Blazor WebAssembly, is just because anything that has to be secure can't be done in the client because of the fact that it all gets downloaded to the client and the client sees all the code.
• 14:13
  SPEAKER_01: Just like an Angular app or a View app or React app, those apps all get downloaded to the client and the client can read all the code.
• 14:21
  SPEAKER_01: Therefore, we don't put anything secure in them.
• 14:24
  SPEAKER_01: Instead, we connect to APIs and have the APIs do the secure work.
• 14:29
  SPEAKER_01: Okay, so that's the one exception, but otherwise, your data access is the exact same for any project type.
• 14:37
  SPEAKER_01: I hope you found this episode helpful.
• 14:39
  SPEAKER_01: I'd appreciate it if you shared it with your social network.
• 14:42
  SPEAKER_01: Thanks for listening.
• 14:43
  SPEAKER_01: And as always, I am Tim Corey.
• 14:45
  SPEAKER_00: Thank you for joining us for this episode of Def Questions.
• 14:48
  SPEAKER_00: Tim is committed to making it easier for you to become a developer.
• 14:52
  SPEAKER_00: If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions.
• 14:59
  SPEAKER_00: You can also send your questions to questions at IamTimcorey.com.
• 15:04
  SPEAKER_00: Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did.
• 15:11
  SPEAKER_00: When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.