Structs & Records

[00:00:00]
>> Spencer Schneidenbach: So classes represent reference types, as I mentioned, but you can declare your own specialized value types, and those are called structs. And structs in the business world, in the in the programming world, unless you're working on high performance code, you're probably not gonna declare a lot of them, but it's important to know that they exist.

[00:00:18]
So, this is a struct of a point, which is probably the most ubiquitous struct example that I could provide, which is essentially to say that this is a thing that will be instantiated and live in the stack, okay? So it will be cleaned up immediately as it leaves scope.

[00:00:38]
It has structural equality built Into it. So as long as X and Y are equal values, two instances of point will be considered equal. So the handling of this, the main reason I bring up Structs is to just let you know that they exist and understand that there are different semantics, memory handling, semantics here.

[00:00:57]
Structs, if you're doing a lot of mathematical operations or, If you're collecting a lot of data, maybe you're doing some complex math or tracking a lot of points on a graph, and you need to do some real strong. If you declare them as a class, you're probably going to get a performance hit, versus if you declare them as a struct, the memory in the stack is a lot faster to access.

[00:01:20]
So, point I wanna make is that structs exist most of the time I don't use them, I use the ones that are declared for me by other frameworks. But this is a structure or a thing that I tend to respect as just an option in case the time arises, where I really need to perform a lot of mathematical operations and I wanna do it on a series of objects, usually like a bunch of points, right?

[00:01:47]
A collection of points, and I need to do some kind of operation or some kind of math on those objects. Structs can be anything, they can even have reference types inside of their properties. I would say that there are things that you can do, and there are things that you should do.

[00:02:03]
And I never, if I declare structs, I never declare them in a way where there are reference types inside, and I always declare them as immutable structures. So they would look something like this. I would construct them such that I close those setters. Look ma, no setter. I close those setters and I just instantiate those values via the constructor, that's structs.

[00:02:28]
Again, high performance most of the time isn't gonna matter, but you need to know that it exists because you will encounter them. Lots of structs inside of that .NET. However, record Types are really cool. Record types are awesome, they are reference types, but they have struct like properties, and they're meant to be kind of just dumb containers of data.

[00:02:51]
So let me show you what they look like. You can see that a public record, this is a public record person, so I'm gonna go ahead and copy and paste this over here. A record is a special type of class that has some implications, right? Again, they're meant to be dumb containers of data.

[00:03:11]
So you can see that this has a name and it has an age. So one of the big features about records is that they are structurally equal by default. Let me show you what that looks like. So I am gonna create a new person and because this is effectively the definition for its constructor, I'm going to give it the name.

[00:03:31]
So I'm gonna say Spencer and I'm gonna say 37 and I'm gonna do the same thing down here, Spencer 37, okay? I'm gonna compare these I'm actually gonna use the double equals this time. Double equals compare and see what happens. Open up my terminal, Control Shift, tilde and do .NET run.

[00:03:57]
Let's see what is it complaining about? I think I typed a character somewhere in here. I did type D tilde. All right, there we go. And you're gonna see that these are now considered equal. So they're kind of like really specialized class types but because of their structural equality, they have a lot of implications in terms of when you're trying to process lots of data and you need to remove duplicates, for instance.

[00:04:22]
Or you just need to define something, a quick object to hold some data. But you don't wanna go through the git public string, name, git set, and write that out for ten different properties. You can use person records instead. They also have this really neat syntax where you can actually create a new person from another person record.

[00:04:45]
So we would say, person one with, and then we'll just change their name to George. And that will effectively give you a person one record, a person two record with the name George, but it will copy over all the other properties that you don't specify. So in this case, person 1, or sorry, person 2 would have the age of 37.

[00:05:13]
Because I'm doing a lot of processing usually to and from databases, this with syntax is not something I do a ton of. Be real with you, but I do use records. Records are a relatively new feature, right? So I do use them, but I don't use the width syntax that said, it's there and it's useful if you need it.

[00:05:34]
It's actually kind of a language feature of F sharp once upon a time. It's a very functional language, and part of that is. it's like, want to create new objects, knit objects from other objects. So it's kind of, you could say that it was kind of born from that.

[00:05:47]
Yes, Mark,
>> Mark: Should you use records or structs or classes for DTOs?
>> Spencer Schneidenbach: That is a great question, actually, I think let's actually address that. Good lead in to records versus classes versus structs. So structs for DTOs, the answer is no. I would use structs when I need them for high performance, because I need to access a large amount of objects do some kind of mathematical operation, and I need to do it very quickly.

[00:06:16]
I'm probably gonna reach for structs. I'm going to use records or classes for DTOs, and I will spoiler alert, the ASP.NET course will almost, will exclusively use classes simply because that is what I'm used to writing. But for DTOs, and I'll explain what that is in a second, I would use records or classes.

[00:06:36]
So I mentioned that records are kind of just, they're dummy kind of holding things. They don't have any behaviors, there's no methods on them, right? So they're just made, their real use is to hold data. Now you can, if you want to add behaviors to records but I choose not to do that.

[00:06:55]
I'm deliberately not kind of showing that because I want records to be used what they're meant to be used for which is just containers for data, okay? Okay, I lost my point there. Yes, so in terms of the question, what is a data transfer object, a DTO? An object, a DTO is simply an object that moves data from one thing to another.

[00:07:18]
When we're talking about the context of an API, this will be important when we're sending JSON to and from a system, because we may send a JSON object, something that looks like this.
>> Spencer Schneidenbach: Something that looks like this, where we have a name, Spencer and we wanna marshal that into our system.

[00:07:44]
Let's make the squiggles go away because they're distracting. Boom, okay. When we're sending data to and from a target system in a format like JSON or some other structured data format, typically once that reaches the C-Sharp system, our .NET system. Them, it'll be represented by something, and in that case, it'll be represented by a, probably a person type, right, where we can take this name and then set it to this, which we'll see plenty of examples of when we get to that section.

[00:08:14]
A DTO is just basically a representation of data that could be incoming or outgoing. So the answer to the question is, I'm gonna use either classes or records, but because I'm used to using classes, I'm probably gonna use classes.