00:00:13.020 --> 00:00:15.020 Umm so.
00:00:16.830 --> 00:00:18.060 On that note.
00:00:20.410 --> 00:00:24.430 Ah, let me get to a spot where things are.
00:00:27.860 --> 00:00:29.230 Feel good.
00:00:30.190 --> 00:00:33.180 And I'll go ahead and share and yeah, so.
00:00:34.580 --> 00:00:38.569 Like I said, this will largely be targeted at UM at new folks
00:00:38.569 --> 00:00:42.686 who haven't really had a chance to dig into this stuff. So that
00:00:42.686 --> 00:00:46.545 being said, anybody who has been here for some time and has
00:00:46.545 --> 00:00:49.890 additional things they wanna add just interrupt me.
00:00:51.380 --> 00:00:54.964 Raise your hand if you want to, but ideally just unmute because
00:00:54.964 --> 00:00:58.491 I probably won't notice that you raised your hand. Just unmute
00:00:58.491 --> 00:01:01.682 and interrupt me and add whatever context you wanna add.
00:01:01.682 --> 00:01:01.850 So.
00:01:02.380 --> 00:01:05.197 Yeah, Brendan, real quick before you start, can you zoom in just
00:01:05.197 --> 00:01:05.760 a little bit?
00:01:06.010 --> 00:01:06.670 Oh yeah, sure.
00:01:07.550 --> 00:01:07.970 Thank you.
00:01:07.550 --> 00:01:10.682 Uh, I'll actually probably let me just close everything I have
00:01:10.682 --> 00:01:10.930 here.
00:01:12.450 --> 00:01:15.618 Yeah, sure. Why not that way, it's not split in half. Be a
00:01:15.618 --> 00:01:16.960 little bit easier to see.
00:01:18.540 --> 00:01:22.955 OK. So yeah, so some of you got this this bit of the talk, but
00:01:22.955 --> 00:01:27.160 I'll pretty quickly go through the layers here kind of talk
00:01:27.160 --> 00:01:31.295 about what's in each one and when you might work with them
00:01:31.295 --> 00:01:35.500 and we'll start from the top, which is really more like the
00:01:35.500 --> 00:01:35.990 bottom.
00:01:38.060 --> 00:01:41.653 So core layer has a lot of the general pieces of code that are
00:01:41.653 --> 00:01:44.390 gonna be shared throughout the entire solution.
00:01:45.650 --> 00:01:49.756 So obviously a good example of that is configuration. So this
00:01:49.756 --> 00:01:53.728 is where all of our our app settings are loaded and stored.
00:01:53.728 --> 00:01:54.920 For the most part.
00:01:56.040 --> 00:02:00.171 And this will be where you can go to find things like the app
00:02:00.171 --> 00:02:01.970 settings key for different.
00:02:02.050 --> 00:02:05.700 The features. So for example carts.
00:02:06.830 --> 00:02:09.742 You can enable or disable this. You can see it's default value
00:02:09.742 --> 00:02:10.250 is enabled.
00:02:11.630 --> 00:02:14.925 You can see that you can disable the models that pop up when you
00:02:14.925 --> 00:02:18.017 add something to the cart. Their their default enabled. They
00:02:18.017 --> 00:02:21.109 depend on carts being enabled obviously because if carts are
00:02:21.109 --> 00:02:24.252 not enabled then do not adding things to a cart and therefore
00:02:24.252 --> 00:02:25.620 you're not getting a modal.
00:02:26.320 --> 00:02:29.858 Umm so but you can see kind of the relationship between these
00:02:29.858 --> 00:02:33.510 settings and all that stuff. A lot of that lives in this layer.
00:02:34.960 --> 00:02:35.650 And.
00:02:36.590 --> 00:02:40.937 Uh, the logic for loading those settings at startup is in here
00:02:40.937 --> 00:02:44.938 as well as the logic for updating those settings from the
00:02:44.938 --> 00:02:48.595 UI that's in the admin. Generally speaking, the code
00:02:48.595 --> 00:02:53.010 that's actually in this layer, the only place you might change.
00:02:53.800 --> 00:02:57.606 Is if you're adding new settings to the CEF config properties
00:02:57.606 --> 00:03:01.412 classes. So for example, you're gonna maybe create a new core
00:03:01.412 --> 00:03:05.034 app setting that's related to the carts feature set. You'd
00:03:05.034 --> 00:03:07.550 probably come in here and add, you know.
00:03:08.440 --> 00:03:12.330 Your public, static, whatever. It's a decimal or something. Uh,
00:03:12.330 --> 00:03:13.910 add your app setting here.
00:03:15.330 --> 00:03:19.350 So you you'd modify that here so that you can access that setting
00:03:19.350 --> 00:03:23.188 globally across the platform. And then if you wanted to expose
00:03:23.188 --> 00:03:26.721 properties to the front end, then you would be looking at
00:03:26.721 --> 00:03:30.071 these self config dot get storefront or CEF config dot
00:03:30.071 --> 00:03:33.969 shared which is down here. These will be the ones that actually
00:03:33.969 --> 00:03:37.989 map the internal back end config values into the object that gets
00:03:37.989 --> 00:03:41.644 sent to the front end so that the front end can be aware of
00:03:41.644 --> 00:03:44.080 what settings are enabled and disabled.
00:03:44.440 --> 00:03:47.608 So those are kind of the really to the only places that you're
00:03:47.608 --> 00:03:50.625 going to be modifying in this layer. Generally speaking, if
00:03:50.625 --> 00:03:53.642 there's any other changes that need to make, you'll, you'll
00:03:53.642 --> 00:03:56.457 probably be wanting to get office hours or just confirm
00:03:56.457 --> 00:03:59.776 that you're going down the right path because this stuff's pretty
00:03:59.776 --> 00:04:03.044 set in stone. And if it breaks, it's gonna break a lot of stuff.
00:04:03.044 --> 00:04:04.150 So kind of one of the.
00:04:05.080 --> 00:04:05.550 Uh.
00:04:06.810 --> 00:04:09.732 The the the bricks at the bottom of the tower and Jenga probably
00:04:09.732 --> 00:04:11.080 don't wanna pull that one out.
00:04:12.280 --> 00:04:12.750 So.
00:04:15.300 --> 00:04:18.512 I'm moving on from there. Some of these, like core and
00:04:18.512 --> 00:04:22.307 utilities, they're really just a lot of general classes that are
00:04:22.307 --> 00:04:25.869 gonna have like this one, got some utilities for things like
00:04:25.869 --> 00:04:26.920 string extensions.
00:04:28.990 --> 00:04:33.189 And the contract classes here, which is basically like our
00:04:33.189 --> 00:04:37.602 shorthand class for a lot of the common like input validation
00:04:37.602 --> 00:04:41.659 stuff that we have. So I'll cover that a little bit more
00:04:41.659 --> 00:04:46.143 later, but these two utilities and core projects, they kind of
00:04:46.143 --> 00:04:50.698 just have a lot of classes like that that are broad useful in a
00:04:50.698 --> 00:04:53.900 lot of places, sort of utility classes that.
00:04:54.890 --> 00:04:56.440 You know or shared through the rest of the code.
00:04:57.730 --> 00:05:00.627 The encryption one obviously has half full of utilities,
00:05:00.627 --> 00:05:03.270 specifically around encrypting and decrypting data.
00:05:03.900 --> 00:05:07.594 Umm. And then the last one here, which is probably the most
00:05:07.594 --> 00:05:11.349 important to know about, is the registry loader. Uh, this is
00:05:11.349 --> 00:05:15.288 another example of one that you probably won't be modifying the
00:05:15.288 --> 00:05:18.674 code that's in this layer much, but you're going to be
00:05:18.674 --> 00:05:22.552 interfacing with it a lot. So the registry loader is the layer
00:05:22.552 --> 00:05:26.061 that handles dependency injection. So what that actually
00:05:26.061 --> 00:05:29.693 means for us is our platform allows us to specify multiple
00:05:29.693 --> 00:05:33.263 implementations of the same interface. So for example, we
00:05:33.263 --> 00:05:34.740 provide integrations to.
00:05:35.410 --> 00:05:39.560 Dozens like a a solid two dozen shipping providers, for example.
00:05:41.200 --> 00:05:45.664 And obviously not every client is gonna use every one of those
00:05:45.664 --> 00:05:47.010 shipping providers.
00:05:47.540 --> 00:05:52.360 And so we have an interface. It's I shipping provider base.
00:05:53.870 --> 00:05:58.156 The registry loader is the the section of the code the the the
00:05:58.156 --> 00:06:01.965 structure. Basically that says when somebody asks for I
00:06:01.965 --> 00:06:06.250 shipping provider base based on their configured settings they
00:06:06.250 --> 00:06:10.128 want us to give them back the UPS provider and the FedEx
00:06:10.128 --> 00:06:14.277 provider and not any of the other implementations. So that's
00:06:14.277 --> 00:06:18.426 all handled here as well as other dependency injection stuff
00:06:18.426 --> 00:06:22.440 like the implementation of models and the database context
00:06:22.440 --> 00:06:24.140 and things like that. So.
00:06:24.450 --> 00:06:27.110 The primary place that you're going to see something like the
00:06:27.110 --> 00:06:29.599 right, the that you're gonna see is you're gonna see this
00:06:29.599 --> 00:06:32.345 registry loader wrapper used in a lot of places, and it'll look
00:06:32.345 --> 00:06:34.490 something like something that that I know has it.
00:06:35.840 --> 00:06:39.094 That I was working in a minute ago. You'll see something that
00:06:39.094 --> 00:06:41.824 looks like this using VAR context equals this whole
00:06:41.824 --> 00:06:45.078 shebang right here. This is just your your ticket to database
00:06:45.078 --> 00:06:48.489 access basically. And your back end code. So this is some you're
00:06:48.489 --> 00:06:51.586 gonna see all over the place. It's just getting a database
00:06:51.586 --> 00:06:54.787 context so it can read or write some data from the database.
00:06:54.787 --> 00:06:58.094 That's what. That's what this section of code does, and that's
00:06:58.094 --> 00:07:01.085 how you do that. So for anybody that's familiar with MVC
00:07:01.085 --> 00:07:01.610 framework.
00:07:02.750 --> 00:07:07.071 That's just the basic if it's in any framework, database context
00:07:07.071 --> 00:07:11.259 and our our database queries are standard LINQ to SQL, we have
00:07:11.259 --> 00:07:15.514 our own custom extension methods I'll talk about here in just a
00:07:15.514 --> 00:07:19.835 minute, but inside of those they boil down to more standard LINQ
00:07:19.835 --> 00:07:20.300 to SQL.
00:07:21.060 --> 00:07:21.950 Umm so.
00:07:22.490 --> 00:07:25.344 Uh, that's generally what the registry load is doing. Again,
00:07:25.344 --> 00:07:28.197 probably not gonna modify the code that's here, but you will
00:07:28.197 --> 00:07:30.770 most certainly see references to it all over the code.
00:07:31.810 --> 00:07:33.380 Uh, so that pretty much covers the core.
00:07:34.980 --> 00:07:37.442 And I kind of do that really fast, but does anybody have any
00:07:37.442 --> 00:07:38.330 questions or thoughts?
00:07:44.980 --> 00:07:48.295 All right. I will move on. So the next is data access layer.
00:07:48.295 --> 00:07:51.446 This is the layer that actually has that entity framework
00:07:51.446 --> 00:07:53.510 database context I was talking about.
00:07:54.760 --> 00:07:59.560 So we are we use entity framework as a code first.
00:08:01.840 --> 00:08:05.693 Rather than database first, so all of our database models are
00:08:05.693 --> 00:08:09.360 defined in this data model shared project under the models
00:08:09.360 --> 00:08:13.337 folder. As you can see, there's quite a few in here and they're
00:08:13.337 --> 00:08:16.941 organized by their schema. So for example, a file in here
00:08:16.941 --> 00:08:20.484 called account in the folder accounts is gonna be in the
00:08:20.484 --> 00:08:24.585 database as accounts dot account or accounts dot contractor and I
00:08:24.585 --> 00:08:25.890 can actually go show.
00:08:27.030 --> 00:08:29.740 And the database that that is.
00:08:30.430 --> 00:08:32.940 True and correct if I can find.
00:08:34.060 --> 00:08:35.150 A good modern one.
00:08:37.900 --> 00:08:41.617 Yeah, so, accounts dot account accounts, dot contractor, et
00:08:41.617 --> 00:08:42.050 cetera.
00:08:42.190 --> 00:08:45.069 Uh, and we do that to group like, uh, like sets of tables
00:08:45.069 --> 00:08:48.146 together so that it's easier to navigate and find what you're
00:08:48.146 --> 00:08:50.180 looking for when you're working in here.
00:08:52.620 --> 00:08:55.868 Something that I think is really important to know is, and I know
00:08:55.868 --> 00:08:59.017 this text over here is probably really small. I I don't think I
00:08:59.017 --> 00:09:01.773 can actually zoom the. Yeah, I can't zoom this solution
00:09:01.773 --> 00:09:02.560 explorer, sorry.
00:09:04.330 --> 00:09:08.038 But uh, one really good thing to note over here is you'll see a
00:09:08.038 --> 00:09:11.629 lot of these tables that have like 2 table names in them. For
00:09:11.629 --> 00:09:15.279 example account is just a flat table name, but then you've got
00:09:15.279 --> 00:09:18.523 account contact. So there's another table in the system
00:09:18.523 --> 00:09:21.940 called contact that's under the context schema. Go figure.
00:09:23.300 --> 00:09:26.822 And whenever you see tables where there are two names like
00:09:26.822 --> 00:09:27.120 this.
00:09:28.140 --> 00:09:31.435 99% of the time, that indicates to you that it's a join table
00:09:31.435 --> 00:09:34.623 between those two, so it's basically representing a many to
00:09:34.623 --> 00:09:37.811 many relationship between the account table and the contact
00:09:37.811 --> 00:09:38.130 table.
00:09:38.710 --> 00:09:42.509 Umm so and if we look in here, we can actually, that's exactly
00:09:42.509 --> 00:09:46.428 what it's doing. It's a contact relationship table where account
00:09:46.428 --> 00:09:48.900 is 1/2 and contact is the other half so.
00:09:49.110 --> 00:09:52.820 And and this is a perfect example of why we have these as
00:09:52.820 --> 00:09:56.273 many to many tables as opposed to just using a direct
00:09:56.273 --> 00:10:00.366 relationship in SQL because the relationship itself may need to
00:10:00.366 --> 00:10:03.947 be described by specific information. For instance here
00:10:03.900 --> 00:10:04.130 Yeah.
00:10:03.947 --> 00:10:07.912 with the account contact we're describing the relationship as
00:10:07.912 --> 00:10:11.685 is primary is billing and transmitted to ERP. If we didn't
00:10:11.685 --> 00:10:15.586 have that information on here, then we would have to somehow
00:10:15.586 --> 00:10:18.400 describe that on either side of the record.
00:10:19.060 --> 00:10:21.650 Either the account of the contact, which would then get
00:10:21.650 --> 00:10:24.101 confused on which one was actually trying to do that
00:10:24.101 --> 00:10:26.968 relationship, and there's cases where there's things that are
00:10:26.968 --> 00:10:29.928 related to each other multiple times with different information
00:10:29.928 --> 00:10:30.390 over time.
00:10:30.980 --> 00:10:35.140 Yeah. So specifically like uh, clarifying on this example.
00:10:36.440 --> 00:10:39.972 The account the contact table is just exactly that. You can kind
00:10:39.972 --> 00:10:43.395 of think of a contact record as like a business card. It's got
00:10:43.395 --> 00:10:46.927 all the relevant information to contact some person and address,
00:10:46.927 --> 00:10:50.513 e-mail, phone, first, last name, all that stuff. It's it's all in
00:10:50.513 --> 00:10:51.110 that table.
00:10:51.690 --> 00:10:57.807 Umm so a an account contact record ties an account to a
00:10:57.807 --> 00:10:58.680 contact.
00:10:59.930 --> 00:11:03.196 And that is the basis of the functionality of our address
00:11:03.196 --> 00:11:05.110 book. So when you go on our site.
00:11:06.150 --> 00:11:09.343 I pull it up, actually. It might even have it open over here. I
00:11:09.343 --> 00:11:10.240 don't, but I will.
00:11:11.040 --> 00:11:11.810 Go to develop.
00:11:12.450 --> 00:11:15.621 Umm, so whenever you go to the site there's an address book
00:11:15.621 --> 00:11:18.739 section where you can associate specific addresses to your
00:11:18.739 --> 00:11:22.069 account. And when you do so, you can mark them as your primary
00:11:22.069 --> 00:11:25.187 shipping or default billing address. And that's what those
00:11:25.187 --> 00:11:28.517 records are. That's what those columns are doing on that table
00:11:28.517 --> 00:11:31.476 is primary means it's your primary shipping address, is
00:11:31.476 --> 00:11:34.700 billing means it's your default billing address. This one is
00:11:34.700 --> 00:11:37.818 just used for something else. That's kind of a convenience
00:11:37.818 --> 00:11:41.042 field for connect. So not as not as relevant to this example
00:11:41.042 --> 00:11:41.940 specifically but.
00:11:42.060 --> 00:11:44.805 It's an extra piece of information we have to add more
00:11:44.805 --> 00:11:46.950 information to this specific relationship.
00:11:47.770 --> 00:11:51.789 Umm, so again, if anybody's seen anything with entity framework,
00:11:51.789 --> 00:11:55.189 a lot of this probably looks somewhat familiar to you.
00:11:55.189 --> 00:11:58.836 Another specific call out here is the SQL schema attribute
00:11:58.836 --> 00:12:02.731 specifically describes how we want this a that we want this to
00:12:02.731 --> 00:12:06.749 be a table in the database and B how we want it to go in. So for
00:12:06.749 --> 00:12:10.397 example it describes it, it's schemas, accounts, the table
00:12:10.397 --> 00:12:11.880 name as account contact.
00:12:13.110 --> 00:12:16.720 If you make new schema and you forget this attribute, your your
00:12:13.980 --> 00:12:14.360 Now.
00:12:16.720 --> 00:12:18.130 schema will not be there.
00:12:19.740 --> 00:12:23.291 Now the reason we're using SQL Schema this attribute as opposed
00:12:23.291 --> 00:12:26.786 to the default one that comes with entity framework is because
00:12:26.786 --> 00:12:30.392 we had to set up to both support TSQL from Microsoft and Oracle,
00:12:30.392 --> 00:12:33.721 and the default set of that they had for it was not working
00:12:33.721 --> 00:12:36.994 properly. So we created a separate one that would actually
00:12:36.994 --> 00:12:40.490 differentiate the two because an Oracle there is no there's no
00:12:40.490 --> 00:12:43.763 schema part, the schema is actually like the login or like
00:12:43.763 --> 00:12:47.036 a main thing. So in their case accounts we would have been
00:12:47.036 --> 00:12:50.143 replaced with clarity or something like that so that it
00:12:50.143 --> 00:12:52.140 would be the same across the board.
00:12:52.230 --> 00:12:56.241 You can have individual schemas, so that's that's for is that we
00:12:56.241 --> 00:12:59.634 were trying to handle the specific scenario of working
00:12:59.634 --> 00:13:02.410 inside Oracle side by side with T SQL on it.
00:13:03.560 --> 00:13:05.590 And so it's just a wrapper that that enables that.
00:13:08.880 --> 00:13:09.150 Hmm.
00:13:10.450 --> 00:13:13.908 Umm. So yeah, I think that generally that covers some of
00:13:13.908 --> 00:13:17.367 the basics of the models, something I'll note in here is
00:13:17.367 --> 00:13:21.128 on a lot of client projects when you're doing customizations,
00:13:21.128 --> 00:13:25.071 creating new tables is something that just happens or adding new
00:13:25.071 --> 00:13:28.954 columns to existing tables. So sometimes that's just needed for
00:13:28.954 --> 00:13:32.230 whatever client customization when you're doing that.
00:13:32.930 --> 00:13:33.500 Umm.
00:13:34.420 --> 00:13:37.063 This is a perfect example to say this for the first time, and
00:13:37.063 --> 00:13:39.280 you'll probably hear it a million more times. Don't
00:13:39.280 --> 00:13:40.090 reinvent the wheel.
00:13:40.670 --> 00:13:43.801 Umm any relationship? You can think that you need to describe
00:13:43.801 --> 00:13:46.982 in the database is already done somewhere in here every minute
00:13:46.982 --> 00:13:49.810 to many one to many. All those kind of things and every
00:13:49.810 --> 00:13:53.041 attribute you're going to need to do it correctly. All of it is
00:13:53.041 --> 00:13:55.970 in here. So if you look around for other tables that have
00:13:55.970 --> 00:13:58.949 similar relationships you can use that as a guide and just
00:13:58.949 --> 00:14:01.928 copy paste and change what you need to change to make that
00:14:01.928 --> 00:14:02.180 work.
00:14:03.240 --> 00:14:06.797 It's a lot better than than spending all the extra time to
00:14:06.797 --> 00:14:10.414 go and try and figure out how all of it is supposed to work
00:14:10.414 --> 00:14:13.970 separately. Just save yourself the time, obviously, try to
00:14:13.970 --> 00:14:16.200 understand it if you can, but don't.
00:14:16.860 --> 00:14:19.214 Don't go and like reinvent the wheel. We have a lot of code in
00:14:19.214 --> 00:14:21.605 here that will do thing. Do the things you need to do is just a
00:14:21.605 --> 00:14:22.950 matter of knowing where to find it.
00:14:23.860 --> 00:14:26.677 So a table that I always like to use is the categories dot
00:14:26.677 --> 00:14:29.636 category table because it's kind of got a little bit of every
00:14:29.636 --> 00:14:31.450 kind of relationship you can imagine.
00:14:32.810 --> 00:14:36.297 As you can see, it's got a lot of different things, so it's got
00:14:36.297 --> 00:14:39.785 types. It's got. I think it has status on here somewhere, maybe
00:14:39.785 --> 00:14:43.108 not. Anyway, it's gotta type, which is one that you're gonna
00:14:43.108 --> 00:14:46.432 come across pretty frequently. It has a relationship back to
00:14:46.432 --> 00:14:49.647 itself to build the category tree. It has relationships to
00:14:49.647 --> 00:14:53.134 some other tables through these IM filter boobys which are good
00:14:53.134 --> 00:14:56.621 example for how those work. It has associated objects which are
00:14:56.621 --> 00:14:59.945 many to manies it has its own related objects which are like
00:14:59.945 --> 00:15:01.470 direct IDs to another table.
00:15:01.740 --> 00:15:05.464 Like foreign keys. And then it's got properties that have their
00:15:05.464 --> 00:15:08.839 own attributes. This table pretty much has anything. It's
00:15:08.839 --> 00:15:12.097 kind of a one stop shop for a code example of how to do
00:15:12.097 --> 00:15:15.705 various relationships. The way that we handle them in CEF. So
00:15:15.705 --> 00:15:19.370 if you need a good reference, the category table file category
00:15:19.370 --> 00:15:22.861 dot CS and the data model shared project is a good starting
00:15:22.861 --> 00:15:23.210 place.
00:15:24.090 --> 00:15:25.250 Umm so.
00:15:26.130 --> 00:15:29.949 Anyway, so that's kind of that's our tables. We have a lot of
00:15:29.949 --> 00:15:30.380 tables.
00:15:31.590 --> 00:15:35.094 Generally speaking, what they do can be pretty well intuited by
00:15:35.094 --> 00:15:38.543 their name and the schema that they're in, but feel free to to
00:15:38.543 --> 00:15:41.938 ask anybody if you're not sure what a table does or what it's
00:15:41.938 --> 00:15:42.430 used for.
00:15:43.030 --> 00:15:46.255 Umm there are some tables in here that aren't really used
00:15:46.255 --> 00:15:49.534 frequently. They're kind of. Maybe they're this whole over
00:15:49.534 --> 00:15:53.037 some old features, or they're kind of tables we built with the
00:15:53.037 --> 00:15:56.372 expectation that they would be used and a lot of times that
00:15:56.372 --> 00:15:59.652 that kind of thing has come in handy for I can think of, I
00:15:59.652 --> 00:16:03.265 think 2 projects right now that are using the advertising schema
00:16:03.265 --> 00:16:06.656 for the first time since at least as long as I've been here.
00:16:06.656 --> 00:16:10.214 And obviously this is built for something at some point. But it
00:16:10.214 --> 00:16:12.660 wasn't really used in the core product and.
00:16:12.740 --> 00:16:15.798 It saved us a lot of time just having those tables ready to
00:16:15.798 --> 00:16:18.907 roll for these projects that rolled up and needed ads and we
00:16:18.907 --> 00:16:22.066 didn't have to go make schema for it. We just had it ready to
00:16:22.066 --> 00:16:25.175 roll. So if you ever working on a project that has a feature
00:16:25.175 --> 00:16:27.570 that sort of aligns with some existing tables.
00:16:28.260 --> 00:16:30.897 More than likely, we're going to reuse those existing tables, and
00:16:30.897 --> 00:16:33.494 if you're ever not sure that's a a good thing to ask, is to make
00:16:33.494 --> 00:16:35.932 sure that you're not gonna use a table that's being used for
00:16:35.932 --> 00:16:37.010 something else or whatever.
00:16:38.020 --> 00:16:38.420 Umm.
00:16:40.130 --> 00:16:43.308 So yeah, uh, that's most of this. The actual database
00:16:43.308 --> 00:16:46.780 context is here, partially here. And then part of it is in
00:16:46.780 --> 00:16:48.310 another another file. But.
00:16:49.480 --> 00:16:52.825 You'll see that a lot of the configuring, the more advanced
00:16:52.825 --> 00:16:56.226 properties of relationships is here, stuff that you can't do
00:16:56.226 --> 00:16:59.739 with the the attributes you have to do with the the fluent API
00:16:59.739 --> 00:17:03.418 for like the cascade deletes and stuff. And this may sometimes be
00:17:03.418 --> 00:17:06.931 necessary if you try to make a migration in any framework says
00:17:06.931 --> 00:17:10.610 something about multiple cascade paths that basically means that.
00:17:11.650 --> 00:17:14.742 The database isn't really sure what to do. If you delete one
00:17:14.742 --> 00:17:17.985 side of the relationship or the other when you've got a foreign
00:17:17.985 --> 00:17:20.874 key relationship and so it doesn't know how to build the
00:17:20.874 --> 00:17:23.966 model and when that's the case, you have to come in here and
00:17:23.966 --> 00:17:26.956 specify that one side of that relationship is not going to
00:17:26.956 --> 00:17:29.540 cascade on delete, meaning that whenever I delete.
00:17:30.870 --> 00:17:34.449 1/2 of the relationship it doesn't delete the other half.
00:17:34.449 --> 00:17:36.670 That way the database knows how to.
00:17:37.380 --> 00:17:40.184 You know, handle that scenario where you delete if, if if you
00:17:40.184 --> 00:17:42.989 if you delete something that doesn't have that uh, then it'll
00:17:42.989 --> 00:17:44.300 know what to do basically so.
00:17:44.680 --> 00:17:48.867 Umm. If you ever see that error this is. This is where you'll
00:17:48.867 --> 00:17:50.150 handle fixing that.
00:17:51.470 --> 00:17:54.157 And there's some, you know, there's a million in one lines
00:17:54.157 --> 00:17:56.889 in here that will tell you exactly pretty much exactly what
00:17:56.889 --> 00:17:59.394 to do. So it's also some additional stuff in here like
00:17:59.394 --> 00:18:02.080 James was saying, there's some stuff about Oracle in here.
00:18:02.160 --> 00:18:05.800 Umm, but yeah, that's.
00:18:06.710 --> 00:18:07.830 All pretty much there.
00:18:10.300 --> 00:18:13.450 And uh, so that's the the main data model stuff. Some of it
00:18:13.450 --> 00:18:16.651 lives over here. This is more like kind of an implementation
00:18:16.651 --> 00:18:19.853 layer where this, this is all the shared files between them.
00:18:19.853 --> 00:18:23.002 The reason this exists is that there was a net 5 version of
00:18:23.002 --> 00:18:26.204 this in here. It's currently unloaded because it hadn't been
00:18:26.204 --> 00:18:29.354 fully working yet. And so for the time being, it's just not
00:18:29.354 --> 00:18:32.450 loaded still in the files. If you wanted to go look at it.
00:18:33.160 --> 00:18:36.198 Umm, but that's if anyone ever curious why they're separated.
00:18:36.198 --> 00:18:39.138 It's because at one point there were two projects that were
00:18:39.138 --> 00:18:42.273 sharing this section of the code so that we didn't have to copy
00:18:42.273 --> 00:18:42.910 paste it all.
00:18:43.510 --> 00:18:44.020 Uh.
00:18:44.930 --> 00:18:48.036 And then you can see this is where like the the rest of the
00:18:48.036 --> 00:18:51.244 context lives for all of the properties for DBB sets and this
00:18:51.244 --> 00:18:54.453 is all the auto generated which we'll talk about in here in a
00:18:54.453 --> 00:18:54.660 bit.
00:18:57.080 --> 00:19:00.695 And so yeah, that's that for those two. The other piece here
00:19:00.695 --> 00:19:04.428 in the data access layer is the searching project. So a little
00:19:04.428 --> 00:19:07.865 bit ago I mentioned that our database querying is largely
00:19:07.865 --> 00:19:11.480 standard LINQ to SQL type stuff that you've probably seen if
00:19:11.480 --> 00:19:14.976 you're familiar with entity framework. But we have our own
00:19:14.976 --> 00:19:18.827 custom extension method. So for example, that's like this filter
00:19:18.827 --> 00:19:21.790 by active right here and this filter by type key.
00:19:24.290 --> 00:19:28.452 These extension methods are basically just convenient ways
00:19:28.452 --> 00:19:32.755 for you to do to basically not have to rewrite the same code
00:19:32.755 --> 00:19:37.269 more than one time. So filter by active is a lot easier to read
00:19:37.269 --> 00:19:41.924 than the equivalent, which would be where X active equals true or
00:19:41.924 --> 00:19:45.380 just X dot active. I guess it's it is a Boolean.
00:19:45.790 --> 00:19:49.447 Umm this is this is a little bit more clear to read, especially
00:19:49.447 --> 00:19:52.818 when you've got a bunch of these wares or a bunch of these
00:19:52.818 --> 00:19:56.360 different filters going through. It's a lot easier to clearly
00:19:56.360 --> 00:19:59.674 read filter by active true where you're clearly saying OK
00:19:59.674 --> 00:20:02.987 obviously this wants to see records where active is true,
00:20:02.987 --> 00:20:06.415 it's just a little bit easier to read and it keeps you from
00:20:06.415 --> 00:20:09.729 having to recreate all that boilerplate every time you do
00:20:09.729 --> 00:20:09.900 it.
00:20:11.710 --> 00:20:14.269 And all of those custom extensions live in this
00:20:14.269 --> 00:20:17.522 searching project and the Owen Data access layer. So you can
00:20:17.522 --> 00:20:20.827 see once again they're divided up into each of the individual
00:20:20.827 --> 00:20:22.000 schemas that are here.
00:20:23.410 --> 00:20:26.131 And then there's a shared folder that has some of these, these
00:20:26.131 --> 00:20:28.593 ones that are kind of broadly used like filter by active
00:20:28.593 --> 00:20:31.357 filter by type key, stuff like that. Those will be shared among
00:20:31.357 --> 00:20:32.480 a lot of different things.
00:20:33.040 --> 00:20:37.315 Uh, and so we can actually go and look at the implementation
00:20:37.315 --> 00:20:41.870 of this. And like I said, these boil down to just more linked to
00:20:41.870 --> 00:20:42.150 SQL.
00:20:43.250 --> 00:20:46.425 You can pass in true, false or null for this and it will handle
00:20:46.425 --> 00:20:49.452 the scenario where if you pass in null it returns your query
00:20:49.452 --> 00:20:52.577 unmodified because null you know it's not gonna guess what you
00:20:52.577 --> 00:20:55.603 want, it's just gonna assume that no means you don't want to
00:20:55.603 --> 00:20:58.530 filter by either active or inactive, so it'll return both.
00:20:59.260 --> 00:21:03.702 UM and then finally it will. It will confirm that your query is
00:21:03.702 --> 00:21:08.213 not null with this little piece right here and then add a filter
00:21:08.213 --> 00:21:12.446 to it where it's active or the active value matches whatever
00:21:12.446 --> 00:21:16.263 you passed in. So what that means is I could make this
00:21:16.263 --> 00:21:17.720 filter back defaults.
00:21:18.390 --> 00:21:21.620 And this would only return records that are inactive.
00:21:22.820 --> 00:21:25.540 So it's just a convenient way for us to.
00:21:25.620 --> 00:21:28.882 Well, basically wrap the functionality of these settings
00:21:28.882 --> 00:21:32.316 or of these filters into a method that you can use in a lot
00:21:32.316 --> 00:21:35.464 of different places without having to do duplicate the
00:21:35.464 --> 00:21:36.780 implementation of them.
00:21:38.360 --> 00:21:41.647 And there are other methods that are a lot more complex than
00:21:41.647 --> 00:21:44.934 filter by active that you know it's it's a little bit that's
00:21:44.934 --> 00:21:48.382 that's an example that shows you what these are doing, but it's
00:21:48.382 --> 00:21:51.830 maybe not a good example because you're like, well, where X dot
00:21:51.830 --> 00:21:55.171 active has the same number of lines, that's true. But this is
00:21:55.171 --> 00:21:58.565 a really trivial example. There are much more complex examples
00:21:58.565 --> 00:21:59.750 here in the filtering.
00:21:58.630 --> 00:21:59.680 Look at uh.
00:22:00.690 --> 00:22:02.350 Look at filter by ID's plural.
00:22:03.790 --> 00:22:04.870 Yeah, it's in here.
00:22:06.070 --> 00:22:09.061 That's a really cool one because it actually makes a predicate
00:22:06.170 --> 00:22:07.570 OK bye IDs.
00:22:09.061 --> 00:22:10.010 with with Lynch kit.
00:22:10.930 --> 00:22:15.272 Yeah. So this one does the reason that it does this is by
00:22:15.272 --> 00:22:20.212 default if you do something like X dot, you know where a list dot
00:22:20.212 --> 00:22:24.703 contains X dot ID or something like that that basically for
00:22:24.703 --> 00:22:29.044 especially for larger numbers like a larger collection is
00:22:29.044 --> 00:22:33.684 going to blow out to a really poorly optimized SQL query that
00:22:33.684 --> 00:22:37.876 runs very slowly. Whereas when you do it with this, the
00:22:37.876 --> 00:22:40.720 predicate builder and do it this way.
00:22:40.900 --> 00:22:44.814 It generates a much more optimal SQL result that runs a lot
00:22:44.814 --> 00:22:45.270 faster.
00:22:46.610 --> 00:22:49.439 And so this is the kind of thing that you definitely don't wanna
00:22:49.439 --> 00:22:51.180 have to reinvent every time you use it.
00:22:53.000 --> 00:22:56.025 And so it's this is a really convenient one. There's also
00:22:56.025 --> 00:22:57.850 filter by excluded IDs right here.
00:22:58.370 --> 00:23:01.774 And there's a couple others. Uh, that do similar things like
00:23:01.774 --> 00:23:05.122 that. But that's a that's a really good example of like, it
00:23:05.122 --> 00:23:08.191 sure would suck to have to rebuild this like predicate
00:23:08.191 --> 00:23:11.539 everywhere that you need it. And so that's what the utility
00:23:11.539 --> 00:23:12.710 methods are here for.
00:23:13.460 --> 00:23:13.900 Umm.
00:23:15.700 --> 00:23:18.880 So uh, does anybody have any questions on that?
00:23:22.420 --> 00:23:26.852 Yeah, I this is Jeremy. I have a question. So you're using entity
00:23:24.880 --> 00:23:25.250 Yeah, sure.
00:23:26.852 --> 00:23:30.881 framework code first. Do you hand edit your migration files
00:23:30.881 --> 00:23:34.977 or is that all handled by the fluent part, the model builder
00:23:34.977 --> 00:23:35.850 and all that?
00:23:35.410 --> 00:23:41.519 We we pretty pretty much never manually modify the migration
00:23:41.519 --> 00:23:42.520 files and.
00:23:43.230 --> 00:23:46.168 Find the there we go migrations. There are quite a number of them
00:23:46.168 --> 00:23:46.390 here.
00:23:47.810 --> 00:23:52.012 We we generally do all of our model configuring via the
00:23:52.012 --> 00:23:56.889 attributes on the actual classes or via the Fluent API in the in
00:23:56.889 --> 00:24:00.940 the context class. If the attributes can't handle it.
00:24:01.580 --> 00:24:06.350 Umm. If you ever run into a scenario which I've made.
00:24:07.070 --> 00:24:09.264 God knows how many schema changes since I've been here,
00:24:09.264 --> 00:24:11.340 and I've never run into a scenario where I needed to
00:24:11.340 --> 00:24:13.651 modify a migration. But if you ever feel like you do, that
00:24:13.651 --> 00:24:16.001 would definitely be a thing where you want to reach out and
00:24:16.001 --> 00:24:17.920 make sure that you're going down the right path.
00:24:18.520 --> 00:24:20.350 Umm, because?
00:24:18.830 --> 00:24:19.220 OK.
00:24:19.450 --> 00:24:22.248 I I think out of everyone who works here, I'm probably the
00:24:22.248 --> 00:24:23.860 only one who's ever had to do it.
00:24:24.320 --> 00:24:27.967 Umm. And I've had to do it with a bunch of them, especially on
00:24:27.967 --> 00:24:31.498 doing like zipper fixes, where if I'm pulling in code from a
00:24:31.498 --> 00:24:35.030 client project and I have to like rewrite their hash so that
00:24:35.030 --> 00:24:37.750 they the migration stacked together correctly.
00:24:39.050 --> 00:24:42.626 And in those cases, usually it's because something about the way
00:24:42.626 --> 00:24:46.091 that it's trying to transition from old from previous snapshot
00:24:46.091 --> 00:24:49.502 to current snapshot of how the database looks. Just something
00:24:49.502 --> 00:24:52.913 about it, it doesn't calculate it correctly and in which case
00:24:52.913 --> 00:24:55.938 like I have to go in and manually adjust like oh, this
00:24:55.938 --> 00:24:59.294 name was actually supposed to be this name, and that puts it
00:24:59.294 --> 00:25:02.319 incorrectly, or it's we're trying to add a column that
00:25:02.319 --> 00:25:05.840 needs to have a default value or change a column from, not from
00:25:05.840 --> 00:25:09.305 nullable to non nullable. So I need to tell it to seed the old
00:25:09.305 --> 00:25:09.580 data.
00:25:09.700 --> 00:25:12.473 Where it was no with the default value, that kind of thing. So
00:25:12.473 --> 00:25:14.850 it's usually very small fixes for that kind of thing.
00:25:15.970 --> 00:25:19.089 And we haven't had to do that in a very long time where there was
00:25:19.089 --> 00:25:22.160 a big change that had to do that we by standardizing how we were
00:25:22.160 --> 00:25:24.948 doing all of this work really helped a lot of that kind of
00:25:24.948 --> 00:25:26.980 thing. So that we have to do that anymore.
00:25:28.850 --> 00:25:30.320 Cool, cool. Thank you.
00:25:31.960 --> 00:25:34.460 Sweet. Any other questions here?
00:25:38.670 --> 00:25:42.338 If not, I've got one other quick thing I can cover in them. We'll
00:25:42.338 --> 00:25:45.673 keep moving on to the the next layer, uh. So while we're in
00:25:45.673 --> 00:25:49.063 here is something you probably noticed was this contract dot
00:25:49.063 --> 00:25:52.342 requires not null contract dot check ballot ID that's that
00:25:52.342 --> 00:25:55.621 contract class I mentioned earlier. It contains a bunch of
00:25:55.621 --> 00:25:58.733 useful methods that handle validation logic. So largely
00:25:58.733 --> 00:25:59.900 input validation but.
00:25:59.980 --> 00:26:03.693 Umm, what that looks like is, you know, do contract dot and
00:26:03.693 --> 00:26:07.653 you've got access to a bunch of these useful things. Now again,
00:26:07.653 --> 00:26:09.880 some of these, like, if we look at.
00:26:09.960 --> 00:26:12.650 To check valid key.
00:26:15.280 --> 00:26:18.747 This is basically all it is. Is basically if a string is not
00:26:18.747 --> 00:26:21.986 null or white space and this again might be one of those
00:26:21.986 --> 00:26:25.566 things we're like, Oh well, why do we need an extension method
00:26:25.566 --> 00:26:27.100 for that? You know what if?
00:26:27.510 --> 00:26:31.529 And it's not that much less text than just doing this well, part
00:26:31.529 --> 00:26:35.548 of the answer there, which this probably wouldn't happen, but if
00:26:35.548 --> 00:26:38.886 a client ever wants to or we ever want to modify what
00:26:38.886 --> 00:26:40.370 constitutes a valid key.
00:26:41.130 --> 00:26:43.715 If everything in the code base is using check valid key for
00:26:43.715 --> 00:26:46.428 checking that we only have to change it in one place, we don't
00:26:46.428 --> 00:26:49.099 have to do a mass search for every instance of string. dot is
00:26:49.099 --> 00:26:49.960 null or white space.
00:26:50.720 --> 00:26:53.560 Umm. And make whatever change we need to make there.
00:26:54.620 --> 00:26:56.600 Same thing with things like check valid ID.
00:26:57.290 --> 00:27:01.082 In in the code we have right now a valid ID is greater than zero
00:27:01.082 --> 00:27:04.757 and not Max value, but we could potentially interface with the
00:27:04.757 --> 00:27:08.140 database system where it's completely different, you know
00:27:08.140 --> 00:27:08.490 maybe.
00:27:08.630 --> 00:27:12.093 I maybe someone decides to have a Joker arc and make a database
00:27:12.093 --> 00:27:15.394 where negative IDs are a thing and we have to interface with
00:27:15.394 --> 00:27:18.640 it. Well now we only have to change what is a valid isn't a
00:27:18.640 --> 00:27:19.830 valid ID in one place.
00:27:21.430 --> 00:27:25.020 Theoretically, and it makes that kind of thing a lot easier.
00:27:22.280 --> 00:27:23.690 Enter the darkest timeline.
00:27:25.020 --> 00:27:28.609 Yeah, yeah. But but if we ever had to go that route, this is
00:27:28.609 --> 00:27:31.846 the kind of thing that makes that easier. Is it's just
00:27:31.846 --> 00:27:35.553 preventing us from having to do tons of manual duplicate labor
00:27:35.553 --> 00:27:39.319 later. And again, there's also more complex examples in here. A
00:27:39.319 --> 00:27:42.790 really nice example that I like to use is check not empty.
00:27:44.850 --> 00:27:47.230 Which this will actually pass that.
00:27:48.630 --> 00:27:52.878 So what? Check not empty does is you can pass a collection or
00:27:52.878 --> 00:27:56.509 null into this and it will return if that record has
00:27:56.509 --> 00:28:00.140 anything. So it's just. It's a nice one that's like.
00:28:00.860 --> 00:28:05.035 If the collection is empty or null, this will return false and
00:28:05.035 --> 00:28:08.480 it's a nice way of like. If this passes, like if a.
00:28:09.200 --> 00:28:12.184 If you get past this, then you know that your collection is not
00:28:12.184 --> 00:28:15.028 only not empty, but also not null and you don't have to null
00:28:15.028 --> 00:28:18.059 check it manually then check if it has anything or anything else
00:28:18.059 --> 00:28:20.903 like that you can. This is just a nice quick way to say it's
00:28:20.903 --> 00:28:23.280 definitely not null and it's definitely not empty.
00:28:23.960 --> 00:28:27.670 Umm. And so that kind of thing is nice and convenient and a lot
00:28:27.670 --> 00:28:30.220 of that stuff you'll find in this contract.
00:28:30.730 --> 00:28:34.867 Umm file. You'll also see that the contract file has a lot that
00:28:34.867 --> 00:28:38.873 start with requires rather than check, so the check ones will
00:28:38.873 --> 00:28:42.816 return true or false based on whatever the condition is. The
00:28:42.816 --> 00:28:46.694 requires are kind of like an assert. They will throw if the
00:28:46.694 --> 00:28:50.636 condition isn't met. So where check valid ID returns true if
00:28:50.636 --> 00:28:54.643 it's valid, false if it's not require is valid ID returns the
00:28:54.643 --> 00:28:58.650 valid ID if it's valid or throws an exception if it's not so.
00:28:58.650 --> 00:29:01.170 This can be used for validating input.
00:29:01.250 --> 00:29:04.520 To like an endpoint or something. If somebody is
00:29:04.520 --> 00:29:08.656 absolutely supposed to pass in a valid ID for some operation,
00:29:08.656 --> 00:29:12.593 then you can use contract requires valid ID and that saves
00:29:12.593 --> 00:29:16.729 you the trouble of having to manually validate it through the
00:29:16.729 --> 00:29:20.799 exception yourself. It's just a nice quick contract dot oops
00:29:20.799 --> 00:29:22.000 requires valid ID.
00:29:22.720 --> 00:29:26.328 Uh. And then whatever your input is, and that's your entire line
00:29:26.328 --> 00:29:26.550 for.
00:29:27.180 --> 00:29:29.718 Basically asserting that an input is valid and throwing an
00:29:29.718 --> 00:29:32.428 exception if it's not so. A lot of times saved with using that
00:29:31.780 --> 00:29:32.740 It also.
00:29:32.428 --> 00:29:33.030 kind of thing.
00:29:33.950 --> 00:29:37.467 Returns the clean devalue, so if you put, if you passed a
00:29:37.467 --> 00:29:41.166 nullable int it will return a non nullable int as the return
00:29:41.166 --> 00:29:44.864 value which will let you know that in your code further down
00:29:41.450 --> 00:29:41.890 Yeah.
00:29:43.150 --> 00:29:43.540 Yes.
00:29:44.864 --> 00:29:48.502 that it no longer needs to do null checks because that is a
00:29:48.502 --> 00:29:49.290 validated ID.
00:29:50.990 --> 00:29:54.802 Yeah. So for example something like this. This is a a nullable
00:29:54.802 --> 00:29:58.614 enumerable of numbers of Ints, if I if I first or default this
00:29:58.614 --> 00:30:02.366 and this is potentially null and this could be null. But this
00:30:02.366 --> 00:30:06.117 line basically cleans that first one to say this if this ever
00:30:06.117 --> 00:30:09.506 gets passed here then you absolutely know for sure that
00:30:09.506 --> 00:30:13.257 you have a valid number here a valid int. So it's either it's
00:30:13.257 --> 00:30:16.040 gotta be greater than zero and not Max value.
00:30:17.480 --> 00:30:22.510 And so yeah, this this returns the value that it validates.
00:30:23.270 --> 00:30:26.168 The check ones don't do that, they just return true or false
00:30:26.168 --> 00:30:29.113 if the condition passes. The requires do return their cleaned
00:30:29.113 --> 00:30:30.870 or their their their asserted value.
00:30:32.000 --> 00:30:32.450 Umm.
00:30:32.200 --> 00:30:34.923 And as part of the input validation type stuff not only
00:30:34.923 --> 00:30:37.597 can you have like the requires not null, but there are
00:30:37.597 --> 00:30:40.611 additional optional arguments to say like at a specific error
00:30:40.611 --> 00:30:43.479 message you want to provide where you can also provide the
00:30:43.479 --> 00:30:46.445 alligator clips and define the type of exception you want to
00:30:46.445 --> 00:30:49.507 throw. So you do have those on virtually all of them where you
00:30:49.507 --> 00:30:52.230 can specify that and override that functionality of the
00:30:52.230 --> 00:30:54.855 default which is just like argument null exception or
00:30:54.855 --> 00:30:57.869 argument invalid argument out of range exception depending on
00:30:57.869 --> 00:31:01.029 which one you're calling. So you can tell it to give a different
00:31:01.029 --> 00:31:02.390 exception if you need it to.
00:31:02.990 --> 00:31:06.376 So they're they're trying to be as versatile as possible while
00:31:06.376 --> 00:31:09.170 being as as consistently implementable as possible.
00:31:13.920 --> 00:31:14.590 Hmm.
00:31:15.980 --> 00:31:19.060 Uh. All right. Any questions on all that stuff?
00:31:24.240 --> 00:31:27.250 Alright, sounds like no. So Oh yeah. Yeah, go ahead. Sorry.
00:31:25.100 --> 00:31:25.810 Sorry, yes.
00:31:25.890 --> 00:31:26.040 But.
00:31:26.820 --> 00:31:27.270 Uh.
00:31:28.440 --> 00:31:28.930 Yeah.
00:31:29.690 --> 00:31:32.060 You talked about that was in contract dot CS.
00:31:33.860 --> 00:31:36.526 That I get that right? Or was there a different class I should
00:31:36.526 --> 00:31:37.710 be looking at at if I wanna?
00:31:38.360 --> 00:31:39.670 Of the predicate thing.
00:31:38.890 --> 00:31:42.800 Go read through these. Yes, I and the the requirements you
00:31:41.630 --> 00:31:42.480 Oh the.
00:31:42.800 --> 00:31:44.390 were just talking about.
00:31:44.360 --> 00:31:47.945 Yeah. So the the the require stuff and check stuff, that's
00:31:47.945 --> 00:31:51.409 all in contract that CS that's gonna be in the UH-00 dot
00:31:51.409 --> 00:31:53.900 clarity dot e-commerce dot core project.
00:31:54.600 --> 00:31:58.765 Umm. And then the predicate builder is in the base search
00:31:55.140 --> 00:31:55.390 Cool.
00:31:58.765 --> 00:32:02.642 extensions dot CS in 01 dot clarity dot ecommerce dot
00:32:02.642 --> 00:32:03.360 searching.
00:32:05.300 --> 00:32:08.432 And yeah, those are both pretty good files to read. Do if you
00:32:08.432 --> 00:32:11.715 wanna just start to familiarize yourself with some stuff, you're
00:32:11.715 --> 00:32:14.847 probably gonna be using a lot as well as it's just, you know,
00:32:14.847 --> 00:32:17.726 could be cool to learn a couple new things if you're not
00:32:17.726 --> 00:32:20.403 familiar with, like the predicate building and stuff
00:32:20.403 --> 00:32:21.110 like that. So.
00:32:21.820 --> 00:32:23.490 Umm yeah.
00:32:22.260 --> 00:32:22.700 Awesome.
00:32:25.520 --> 00:32:29.560 OK, so I'm gonna keep moving. Then I'm gonna close everything
00:32:29.560 --> 00:32:33.730 I have here. The next layer is 02 interfaces. This layer pretty
00:32:33.730 --> 00:32:37.574 quick to go through the majority of what's in here is just
00:32:37.574 --> 00:32:41.158 defining interfaces for implementations that will come
00:32:41.158 --> 00:32:45.393 later. So an important thing to note at this point is obviously,
00:32:45.393 --> 00:32:49.629 as you saw, we have a class that represents every database table
00:32:49.629 --> 00:32:53.408 and an instance of that class represents an instance of a
00:32:53.408 --> 00:32:54.450 database record.
00:32:56.140 --> 00:32:59.137 However, for a variety of reasons, we don't want to return
00:32:59.137 --> 00:33:02.184 database entities to the front end for technical limitation
00:33:02.184 --> 00:33:03.910 reasons and for security reasons.
00:33:04.990 --> 00:33:05.640 So.
00:33:08.130 --> 00:33:11.702 I'm sorry if you can hear my cat just howling. Give me a minute.
00:33:11.702 --> 00:33:12.910 He's being very noisy.
00:33:22.460 --> 00:33:24.792 OK, sorry about that. I don't know if you could hear that,
00:33:24.792 --> 00:33:24.950 but.
00:33:25.830 --> 00:33:29.000 He was sounded like a I don't know.
00:33:30.660 --> 00:33:33.080 Some kind of squeaky wheel anyway.
00:33:35.400 --> 00:33:39.370 So what I was saying, we don't return database entities over
00:33:39.370 --> 00:33:43.404 the wire to the front end. So instead what we have is a model
00:33:43.404 --> 00:33:44.380 of that record.
00:33:45.650 --> 00:33:48.625 And so from here down, you'll start to see references to
00:33:48.625 --> 00:33:48.990 models.
00:33:49.640 --> 00:33:53.200 Umm. And effectively what those models are is there, generally
00:33:53.200 --> 00:33:56.816 speaking, they're they're close to 1 to one with the table, but
00:33:56.816 --> 00:33:59.753 we can define how the information on the table gets
00:33:59.753 --> 00:34:02.861 into the model and how information from the model gets
00:34:02.861 --> 00:34:06.420 back into the table. And that's done in the mapping layer that
00:34:06.420 --> 00:34:09.923 will cover here in a bit. But that's just to start clarifying
00:34:09.923 --> 00:34:13.595 on terminology that you'll start seeing the term models in a lot
00:34:13.595 --> 00:34:16.759 of places and generally speaking, in CEF, we're talking
00:34:16.759 --> 00:34:17.550 about a model.
00:34:18.320 --> 00:34:21.796 Of a database record pretty much so a it's a a DTO, a data
00:34:21.796 --> 00:34:25.271 transfer object, and then another term you'll start seeing
00:34:25.271 --> 00:34:28.982 frequently is workflows. We'll cover more detail and workflows
00:34:28.982 --> 00:34:32.693 here in a bit, but workflows is the term we used. It basically
00:34:32.693 --> 00:34:34.990 describes just general business logic.
00:34:35.330 --> 00:34:39.405 Umm, so uh. So yeah, the interfaces, models defines
00:34:39.405 --> 00:34:43.715 exactly what you probably guessed based on what I just
00:34:43.715 --> 00:34:48.730 said, interfaces of models. So I account association model and.
00:34:49.670 --> 00:34:52.570 You know different things like that. So we were looking at like
00:34:52.570 --> 00:34:55.243 I and we were looking account contact earlier. So here's I
00:34:55.243 --> 00:34:56.240 account contact model.
00:34:57.310 --> 00:35:00.274 There's a generated half that's auto generated. Again, we'll
00:35:00.274 --> 00:35:03.189 we'll double back to the the auto generated stuff here in a
00:35:03.189 --> 00:35:06.396 bit and then there's an extended one that contains the additional
00:35:06.396 --> 00:35:09.408 properties. This is a little different in current version and
00:35:09.408 --> 00:35:12.323 the current version stuff. This project is the version just
00:35:12.323 --> 00:35:13.440 before our current one.
00:35:14.780 --> 00:35:17.620 And so in 2022.4 and newer.
00:35:18.220 --> 00:35:21.297 UM, almost every property is handled for you in the auto
00:35:21.297 --> 00:35:21.890 generation.
00:35:23.720 --> 00:35:27.234 But in older versions 2022.3 and earlier, they'll be split into
00:35:27.234 --> 00:35:30.694 two separate files, and in the extended one you'll have to add
00:35:30.694 --> 00:35:32.670 in your custom properties yourself.
00:35:33.470 --> 00:35:36.277 And again, don't reinvent the wheel. There's a million
00:35:36.277 --> 00:35:39.287 examples of what to do and how to do it. And if you're not
00:35:39.287 --> 00:35:40.920 sure, feel free to ask somebody.
00:35:42.100 --> 00:35:42.570 But.
00:35:44.610 --> 00:35:48.163 Another another nice thing to call out while we're here. Don't
00:35:48.163 --> 00:35:51.435 don't modify auto generated files it it should go without
00:35:51.435 --> 00:35:54.931 saying, but it happens all the time. It's just the thing that
00:35:54.931 --> 00:35:58.146 you know, sometimes you don't even notice that it's auto
00:35:58.146 --> 00:36:01.699 generated until you go and make your PR and get a comment, but
00:36:01.699 --> 00:36:04.914 always a good thing to check every out of generated file
00:36:04.914 --> 00:36:08.354 should have autogenerated right at the top. So if you're not
00:36:08.354 --> 00:36:11.569 sure if you're looking at the new file you've never seen
00:36:11.569 --> 00:36:15.010 before, probably check this before you make any changes just
00:36:15.010 --> 00:36:16.250 to be sure you're not.
00:36:16.330 --> 00:36:18.567 Going to have to figure out another way to do whatever it is
00:36:18.567 --> 00:36:19.300 you're trying to do.
00:36:20.350 --> 00:36:23.457 As well I'm I'm doing everything I can to move more and more of
00:36:23.457 --> 00:36:24.330 the files to both.
00:36:24.590 --> 00:36:29.160 I have a suffix of generated or extended so that it's more clear
00:36:29.160 --> 00:36:33.660 as well that this is a generated file versus the extended ones.
00:36:33.860 --> 00:36:37.335 Yeah, the extended ones, anything that's dot extended dot
00:36:37.335 --> 00:36:41.169 CS, those are safe to manually modify. Those are intended to be
00:36:41.169 --> 00:36:44.524 manually modified, whereas anything that's generated or
00:36:44.524 --> 00:36:48.478 another example would be if it's underneath a folder called T4 or
00:36:48.478 --> 00:36:52.312 something like that, you're most most certainly not going to be
00:36:52.312 --> 00:36:53.750 modifying those by hand.
00:36:54.410 --> 00:36:57.991 Umm, so uh, just a good thing to call out. And like I said, we'll
00:36:57.991 --> 00:37:01.191 we'll double back and we'll cover what the code generation
00:37:01.191 --> 00:37:04.663 does, what we use it for and how to how to work with it here in
00:37:04.663 --> 00:37:07.918 just a bit. But yeah, that's pretty much all that's in here
00:37:07.918 --> 00:37:08.080 is.
00:37:08.750 --> 00:37:11.900 The interfaces for the various models of database tables.
00:37:13.110 --> 00:37:16.502 And the interface is workflows. It is interfaces for the
00:37:16.502 --> 00:37:19.893 workflow. So the general business logic. So again here's
00:37:19.893 --> 00:37:23.522 that four folder I was talking about. So anything under this
00:37:23.522 --> 00:37:24.890 folder you're probably.
00:37:25.560 --> 00:37:30.588 Uh, you're you're just not going to be modifying manually, and it
00:37:30.588 --> 00:37:35.236 generates are the outputs for that, that's that's the manual
00:37:35.236 --> 00:37:35.540 one.
00:37:37.080 --> 00:37:41.541 I guess it's in here and yeah, yeah, OK. Put them all in here.
00:37:41.541 --> 00:37:45.718 So, for example, all of these I account contact were flow.
00:37:45.718 --> 00:37:49.825 Workflow derives from inable workflow base which contains
00:37:49.825 --> 00:37:54.073 some in this layer. It's just the interfaces of some useful
00:37:54.073 --> 00:37:58.392 operations for things that have names. So you can read out a
00:37:58.392 --> 00:38:02.570 record by its name. You can check if something exists by a
00:38:02.570 --> 00:38:07.030 specific name, you can resolve it by its ID, key and name and.
00:38:07.130 --> 00:38:10.912 A model and all the different stuff. All these useful methods
00:38:10.912 --> 00:38:14.632 are in here auto generated for you to have access to for any
00:38:14.632 --> 00:38:16.340 table that this is nameable.
00:38:18.460 --> 00:38:19.370 And.
00:38:20.850 --> 00:38:24.638 So and then additionally, there are these like I account contact
00:38:24.638 --> 00:38:27.785 workflow that contain these methods that are not auto
00:38:27.785 --> 00:38:31.107 generated but are relevant business logic so to speak to
00:38:31.107 --> 00:38:34.429 the account contact stuff. So these are basic stuff like
00:38:34.429 --> 00:38:38.100 marking an account contact as your default billing and primary
00:38:38.100 --> 00:38:41.130 shipping or as neither default billing or shipping.
00:38:42.240 --> 00:38:45.078 And this just handled those operations in a concise way so
00:38:45.078 --> 00:38:48.204 that once again, you don't have to duplicate the logic for them,
00:38:48.204 --> 00:38:51.186 you can just call a method that does the thing you want it to
00:38:51.186 --> 00:38:51.330 do.
00:38:53.700 --> 00:38:57.350 So yeah, the other the other thing you'll see in here is
00:38:57.350 --> 00:39:01.064 providers. You'll start to see interfaces for those. So I
00:39:01.064 --> 00:39:04.714 mentioned earlier the shipping providers. So we've got I
00:39:04.714 --> 00:39:08.300 shipping provider based that defines the interface for.
00:39:09.000 --> 00:39:12.660 A A provider that returns shipping rates.
00:39:13.240 --> 00:39:16.262 Uh, I know I keep pushing things down the road, but we will cover
00:39:16.262 --> 00:39:19.146 providers more here in just a minute. We're actually almost at
00:39:19.146 --> 00:39:19.970 that later anyway.
00:39:20.530 --> 00:39:24.100 Uh, uh. But this is where you'll find interfaces for those.
00:39:26.750 --> 00:39:28.040 Any questions on all that?
00:39:35.750 --> 00:39:39.293 If not, I will keep on moving. Ah alright. So looking at the
00:39:39.293 --> 00:39:43.069 models and mapping layer. So now we're starting to get into some
00:39:43.069 --> 00:39:46.554 of the implementation of those interfaces, specifically the
00:39:46.554 --> 00:39:49.341 models folder. The models project will have the
00:39:49.341 --> 00:39:53.175 implementation of the interfaces of models that we defined. Here.
00:39:53.175 --> 00:39:56.950 It's laid out almost exactly the same as the other one was. It's
00:39:56.950 --> 00:40:00.377 just that instead of having I before them, they don't. And
00:40:00.377 --> 00:40:03.862 instead of being interfaces, they're classes that implement
00:40:03.862 --> 00:40:06.940 those interfaces. So here's I account contact model.
00:40:07.640 --> 00:40:10.758 Umm. And again some auto generation handles some of this
00:40:10.758 --> 00:40:13.110 for you. Some of it's not handled for you.
00:40:13.710 --> 00:40:17.533 Umm. And again you you can avoid reinventing the wheel and just
00:40:17.533 --> 00:40:21.296 checking other code samples to see what you need to do to make
00:40:21.296 --> 00:40:24.999 this all correct. And newer CEF. Again, this is another place
00:40:24.999 --> 00:40:28.822 where much of this is done for you, much if not pretty much all
00:40:28.822 --> 00:40:29.180 of it.
00:40:30.780 --> 00:40:33.590 But in older versions you will have to do some of this part if
00:40:33.590 --> 00:40:35.150 you're adding new tables manually.
00:40:36.480 --> 00:40:39.549 And and you can you can check other tables to see what it is
00:40:39.549 --> 00:40:41.410 you should be pulling over manually.
00:40:43.610 --> 00:40:46.680 So that's the models one again pretty cut and dry, it's just.
00:40:47.860 --> 00:40:51.621 The implementation of those interfaces. Uh, so now we're
00:40:51.621 --> 00:40:55.976 moving up to mapping. So this is what I was talking about earlier
00:40:55.976 --> 00:41:00.132 where this is the project that actually defines how a database
00:41:00.132 --> 00:41:04.223 record ties back to or ties into a model and how a model goes
00:41:04.223 --> 00:41:06.070 back into a database record.
00:41:07.060 --> 00:41:10.621 And so this one generates all the code that handles that, but
00:41:10.621 --> 00:41:14.411 that code generation is actually driven by attributes at the data
00:41:14.411 --> 00:41:15.100 model layer.
00:41:15.820 --> 00:41:20.284 Umm so if you have a property that you never want to be
00:41:20.284 --> 00:41:25.306 visible on the storefront, for example the users password hash
00:41:25.306 --> 00:41:26.900 or things like that.
00:41:27.460 --> 00:41:28.190 Umm.
00:41:30.910 --> 00:41:34.700 That's the interface I am wrong and it's in here too.
00:41:35.920 --> 00:41:40.085 The password hash has don't map in. Don't map out, so we're
00:41:40.085 --> 00:41:43.972 effectively saying this. This specific database column.
00:41:43.972 --> 00:41:48.136 Anything in there should never be allowed to map out. There
00:41:48.136 --> 00:41:52.023 should never be a user model that's been created by the
00:41:52.023 --> 00:41:56.535 mapping layer that contains the user's password hash for obvious
00:41:56.535 --> 00:41:57.090 reasons.
00:41:57.830 --> 00:42:02.001 Umm, so these don't map or force map attributes which will cover
00:42:02.001 --> 00:42:05.786 I'll. I'll go through more of those here in just a second.
00:42:05.786 --> 00:42:09.700 Those are how you dictate the behavior of the mapping layer.
00:42:10.220 --> 00:42:15.790 Umm. And those live on the actual tables, so by default.
00:42:17.640 --> 00:42:22.018 Or I guess before I cover that bit the self mapping layer has
00:42:22.018 --> 00:42:26.324 three layers that it maps things full, which is I called the
00:42:26.324 --> 00:42:29.360 everything in the kitchen sink. It's just.
00:42:30.030 --> 00:42:33.549 Anything that isn't in explicitly for like told not to
00:42:33.549 --> 00:42:37.515 map out ever. It will will come out on a full mapping. It's a
00:42:37.515 --> 00:42:41.673 lot of data and you would use a full mapping on the front end in
00:42:41.673 --> 00:42:45.639 a place where you need to use the majority of the information
00:42:45.639 --> 00:42:49.669 on that record like a product details page or maybe a category
00:42:49.669 --> 00:42:53.507 landing page. Stuff like that where you're using a lot more
00:42:53.507 --> 00:42:57.473 than just name. Maybe an image, maybe a custom key, something
00:42:57.473 --> 00:42:59.840 like that. You're going to be using.
00:43:00.340 --> 00:43:02.948 Multiple images and associations and various other related
00:43:02.948 --> 00:43:05.378 objects are going to have relevant information to what
00:43:05.378 --> 00:43:08.162 you're trying to display on the page or the business logic are
00:43:08.162 --> 00:43:10.858 trying to implement on the back end. Then you're gonna use a
00:43:10.858 --> 00:43:11.830 full mapping for that.
00:43:13.250 --> 00:43:16.864 And then we have the light mapping, which is by default
00:43:16.864 --> 00:43:20.414 light and list the light and list are the next two. By
00:43:20.414 --> 00:43:24.479 default they behave largely the same, which is that they don't
00:43:24.479 --> 00:43:28.480 map out associated objects and everything else is handled by.
00:43:31.230 --> 00:43:35.061 By attributes. So you would use a light mapping for place where
00:43:35.061 --> 00:43:38.592 you're displaying a handful of things. Maybe you know 234,
00:43:38.592 --> 00:43:41.765 maybe five things and you're getting a little bit of
00:43:41.765 --> 00:43:45.296 information about each one a little bit more than the bare
00:43:45.296 --> 00:43:49.007 minimum, but a lot less than a full details page that's gonna
00:43:49.007 --> 00:43:52.778 be like your light listing and then a list. Sorry Lightmapping
00:43:52.778 --> 00:43:56.548 a list mapping is the lowest the least amount of data that you
00:43:56.548 --> 00:43:59.900 can map out, and it's typically just a tiny smattering.
00:44:00.350 --> 00:44:04.399 Of like it's got your records ID, maybe it's name, custom key
00:44:04.399 --> 00:44:08.056 and very little else. It's typically just a handful 345
00:44:08.056 --> 00:44:12.039 fields from that Tate from that record and nothing else. And
00:44:12.039 --> 00:44:15.761 that's when you're listing out dozens of that record and
00:44:15.761 --> 00:44:19.353 performance is really performance could be a lot worse
00:44:19.353 --> 00:44:23.140 if you're trying to map out everything on that record so.
00:44:24.840 --> 00:44:28.160 You can drive the results of those different things with
00:44:28.160 --> 00:44:31.770 these mapping attributes here at the data model layer, so I'm
00:44:31.770 --> 00:44:34.740 going to see if I can find a good example in here.
00:44:42.460 --> 00:44:46.245 There's some more in there that we'll talk about, but the
00:44:46.245 --> 00:44:50.356 category is probably got some category like I said might go to
00:44:50.356 --> 00:44:54.467 table, but you can drive that with these different attributes.
00:44:54.467 --> 00:44:58.512 So here's a good one. OK. So by default a related object like
00:44:58.512 --> 00:45:01.840 the currency, the restocking fee amount, currency.
00:45:02.510 --> 00:45:06.010 This would not map out below the full mapping layer, but this
00:45:06.010 --> 00:45:09.227 force map out with light attribute says even though that
00:45:09.227 --> 00:45:12.896 is the default behavior, we want to override that and always map
00:45:12.896 --> 00:45:16.340 the currency out at light or above so light or full. So at a
00:45:16.340 --> 00:45:19.388 list mapping of this of categories you still wouldn't
00:45:19.388 --> 00:45:22.831 get the full restocking fee amount currency object on there,
00:45:22.831 --> 00:45:26.105 but it'll light mapping where you normally wouldn't. This
00:45:26.105 --> 00:45:28.080 attribute makes it so that you do.
00:45:30.130 --> 00:45:33.371 Vice versa, we have these attributes for don't map out
00:45:33.371 --> 00:45:37.260 ever on these that handle things that are these really only exist
00:45:37.260 --> 00:45:40.795 in the data model like it says here? These are only here to
00:45:40.795 --> 00:45:43.918 satisfy relationship requirements. They should never
00:45:43.918 --> 00:45:47.571 be used. So these are mostly mostly exist pretty much just to
00:45:47.571 --> 00:45:50.930 describe a relationship, probably to configure it in the
00:45:50.930 --> 00:45:54.524 fluent API or something. And you're not really ever gonna be
00:45:54.524 --> 00:45:57.765 querying against these or returning these to the front
00:45:57.765 --> 00:45:58.000 end.
00:45:58.770 --> 00:46:01.979 In that case, we never want to map them out because it's just
00:46:01.979 --> 00:46:05.240 noise really to the front end it it doesn't need this data and
00:46:05.240 --> 00:46:08.553 it's extra extra stuff we have to read from the database. Extra
00:46:08.553 --> 00:46:11.866 stuff we have to send over the wire. We don't need it, so we'll
00:46:11.866 --> 00:46:15.230 just don't map out ever on these and then you can also use don't
00:46:15.230 --> 00:46:18.336 map out ever on things that similar to the other are secure
00:46:18.336 --> 00:46:21.286 information that should only ever be explicitly manually
00:46:21.286 --> 00:46:24.651 queried for. We don't ever want to accidentally map this out, so
00:46:24.651 --> 00:46:27.963 that's like the password hash or any other payment related like
00:46:27.963 --> 00:46:29.930 payment tokens and stuff on a wallet.
00:46:30.000 --> 00:46:30.380 Model.
00:46:32.160 --> 00:46:35.559 All that kind of stuff we don't want to just send Willy nilly
00:46:35.559 --> 00:46:37.970 without it being a very intentional change.
00:46:39.670 --> 00:46:42.820 That somebody wrote because you know, if it's intentional, it
00:46:42.820 --> 00:46:46.020 should be easier to catch any code review and we can make sure
00:46:46.020 --> 00:46:49.068 that it doesn't go through, whereas if it's auto generated,
00:46:49.068 --> 00:46:52.370 it may get lost in the sauce and be a little bit harder to find.
00:46:53.470 --> 00:46:55.800 So so yeah.
00:46:58.420 --> 00:47:02.293 That's some of those. There's also like 4 snap out with lists.
00:47:02.293 --> 00:47:05.981 There's, uh, don't map out, ever. There's, uh, there's some
00:47:05.981 --> 00:47:09.854 of these more complex ones we saw in that other file of things
00:47:09.854 --> 00:47:13.235 like allow map in with relate workflows but don't auto
00:47:13.235 --> 00:47:16.985 generate. So what that means is that if I were to map in AKA
00:47:16.985 --> 00:47:20.735 like create, update, whatever record and I passed in a model
00:47:20.735 --> 00:47:24.546 that had a language on it then what this does is it allows me
00:47:24.546 --> 00:47:27.988 to update the language that's assigned on a record that
00:47:27.988 --> 00:47:28.910 already exists.
00:47:28.960 --> 00:47:32.475 Or create a record with language that's passed in, but it's not
00:47:32.475 --> 00:47:35.825 gonna auto generate a language based on what I pass in. It's
00:47:35.825 --> 00:47:39.120 gonna try to resolve it to an existing one in the database.
00:47:39.850 --> 00:47:43.441 Umm, so uh, that's what that means is it allows it to map in.
00:47:43.441 --> 00:47:46.916 So you're allowed to send it into to create or updates, but
00:47:46.916 --> 00:47:50.449 it's not gonna auto generate a language based on this if one
00:47:50.449 --> 00:47:52.650 doesn't match what you're passing in.
00:47:54.030 --> 00:47:57.628 And so there's a similar one to that for associations, which is
00:47:57.628 --> 00:48:01.281 basically the list ones the the menu to menus and those would be
00:48:01.281 --> 00:48:04.597 the same deal where there's an allow map in with associate
00:48:04.597 --> 00:48:07.633 workflows but don't auto generate where if you've got
00:48:07.633 --> 00:48:10.949 multiple things you wanna resolve to or attach to, but you
00:48:10.949 --> 00:48:14.265 don't want to auto generate them if they don't exist. That
00:48:14.265 --> 00:48:15.670 attribute also exists so.
00:48:16.980 --> 00:48:21.608 I know that probably was pretty dense, but any questions on the
00:48:21.608 --> 00:48:22.620 mapping stuff?
00:48:33.870 --> 00:48:38.458 All right. Uh, then I will keep on chugging. Uh, so next is
00:48:38.458 --> 00:48:42.969 providers I mentioned these earlier, but these are sort of
00:48:42.969 --> 00:48:45.950 like modular pieces of logic that are.
00:48:46.630 --> 00:48:49.715 We typically use a provider anywhere where the
00:48:49.715 --> 00:48:53.850 implementation could potentially vary. There could be multiple
00:48:53.850 --> 00:48:57.000 implementations of the same sort of end result.
00:48:58.220 --> 00:49:02.787 Or we're interfacing with like a third party. Different things
00:49:02.787 --> 00:49:07.281 like that. So good examples are inventory is a great example.
00:49:07.281 --> 00:49:09.890 Pricing is a good example shipping.
00:49:11.900 --> 00:49:15.176 Payments. Those are some of the ones you're gonna interface with
00:49:15.176 --> 00:49:18.301 most commonly. And what you'll notice in each one of these is
00:49:18.301 --> 00:49:21.225 that we've got all these different shipping providers and
00:49:21.225 --> 00:49:24.551 some different pricing logic and a bunch of payment providers and
00:49:24.551 --> 00:49:26.970 some different inventory calculation providers.
00:49:28.590 --> 00:49:32.833 Each one of these can be enabled to dictate how how inventory is
00:49:32.833 --> 00:49:37.010 calculated, how we determine if a product is or isn't in stock.
00:49:38.190 --> 00:49:41.942 We can determine how pricing is calculated, so you have, you
00:49:41.942 --> 00:49:45.940 know flat is basically just if a record says it's $5 and it's $5
00:49:45.940 --> 00:49:49.815 and that's it. But then we have more advanced stuff like price
00:49:49.815 --> 00:49:53.320 rules, which is the most advanced where you can dictate.
00:49:54.320 --> 00:49:58.970 Extremely precise rules that describe a price, so you can say
00:49:58.970 --> 00:49:59.270 for.
00:50:00.710 --> 00:50:05.280 This product people that have this user role.
00:50:06.360 --> 00:50:10.700 Uh, get X number of dollars off or even more complex could be
00:50:10.700 --> 00:50:15.040 things like for all products in this category users with this
00:50:15.040 --> 00:50:19.660 user role get 10% off. Something like that, right? So price rules
00:50:19.660 --> 00:50:23.860 do really complex, extremely in depth pricing calculations.
00:50:24.560 --> 00:50:25.410 And.
00:50:26.810 --> 00:50:32.370 Flat is just $5 and Yep, sounds good to me and so obviously.
00:50:34.010 --> 00:50:37.591 There are different use cases for each one. There's also
00:50:37.591 --> 00:50:41.611 tiered pricing, which is sort of a price lists, if you will. If
00:50:41.611 --> 00:50:45.254 you've seen that in other platforms, it's basically a way
00:50:45.254 --> 00:50:48.772 of setting up different prices that have a sort of name
00:50:48.772 --> 00:50:52.540 associated to them. And then you can associate that name to
00:50:52.540 --> 00:50:56.435 different accounts or different catalogs, more or less to say
00:50:56.435 --> 00:51:00.141 that there could be like a general price list, that's just
00:51:00.141 --> 00:51:01.020 your standard.
00:51:01.770 --> 00:51:05.726 If you're if you're not like a, you know a business customer or
00:51:05.726 --> 00:51:09.249 something, and then a lot of clients, what they'll do is
00:51:09.249 --> 00:51:13.019 they'll actually use the tiered pricing and sync in customer
00:51:13.019 --> 00:51:16.665 specific pricing and that basically is just like there's a
00:51:16.665 --> 00:51:19.693 price list that has that customer's name or that
00:51:19.693 --> 00:51:23.216 customer's ID in it and that that price list becomes the
00:51:23.216 --> 00:51:26.924 basis for what that customer sees when they're browsing the
00:51:26.924 --> 00:51:28.840 catalog or looking at products.
00:51:30.080 --> 00:51:32.983 And their prices will actually display differently because of
00:51:32.983 --> 00:51:34.200 their personal price list.
00:51:35.380 --> 00:51:38.811 We can also use tiered pricing to break uh pricing out by
00:51:38.811 --> 00:51:42.479 different quantities, different currencies, all the different
00:51:42.479 --> 00:51:43.070 stuff, so.
00:51:44.500 --> 00:51:47.845 This one you'll start. You'll see pretty frequently price
00:51:47.845 --> 00:51:50.901 rules is it's pretty rare that anybody needs the the
00:51:50.901 --> 00:51:54.246 extensiveness of this, but it has. It's been used several
00:51:54.246 --> 00:51:56.610 times. Flat pricing is the the one that.
00:51:57.320 --> 00:52:00.206 Uh, usually. For simpler projects, it's gonna be this.
00:52:00.206 --> 00:52:03.617 They don't usually need anything more complex than this, but for
00:52:03.617 --> 00:52:06.923 projects that are more complex, it's pretty rare that they use
00:52:06.923 --> 00:52:09.861 just flat pricing. They'll typically use something more
00:52:09.861 --> 00:52:11.960 advanced tiered pricing or price rules.
00:52:13.740 --> 00:52:16.917 But yeah, that's basically what the providers do is they are
00:52:16.917 --> 00:52:19.729 modular pieces of logic that you can sub in different
00:52:19.729 --> 00:52:20.770 implementations for.
00:52:21.220 --> 00:52:24.370 Umm. And like I mentioned earlier.
00:52:25.450 --> 00:52:28.951 The implementation that you get back is determined by the
00:52:28.951 --> 00:52:32.330 settings and it's served to you by the registry loader.
00:52:33.030 --> 00:52:33.500 Umm.
00:52:34.420 --> 00:52:39.007 So while we're in here, I'll take a quick look and show you
00:52:39.007 --> 00:52:43.976 guys what the what I mean by by fed by your settings is it looks
00:52:43.976 --> 00:52:47.951 these these registry files are what actually handle
00:52:47.951 --> 00:52:52.461 registering. Go figure and implementation for an interface
00:52:52.461 --> 00:52:52.690 so.
00:52:53.370 --> 00:52:56.807 This constructor runs at the when the app starts up and what
00:52:56.807 --> 00:53:00.075 it's going to do is it's going to check each one of these
00:53:00.075 --> 00:53:03.513 different configs and determine if the configuration for the
00:53:03.513 --> 00:53:07.006 specific provider is valid, and if it is, then it goes in and
00:53:07.006 --> 00:53:10.049 registers that for this interface we want to add this
00:53:10.049 --> 00:53:13.542 implementation we want to use flat pricing if flat pricing is
00:53:13.542 --> 00:53:13.880 valid.
00:53:15.140 --> 00:53:15.730 So.
00:53:16.360 --> 00:53:19.760 Uh, what? Those is valid methods look like and I'll find one
00:53:19.760 --> 00:53:23.160 that's not the flat one because it's gonna be basic. Is this
00:53:23.160 --> 00:53:26.504 right now all it's doing is just checking for this specific
00:53:26.504 --> 00:53:30.015 provider. All it cares about is did you actually type in price
00:53:30.015 --> 00:53:33.359 rules, pricing provider into your enabled providers list in
00:53:33.359 --> 00:53:36.927 your settings if you did or this is default and activated which
00:53:36.927 --> 00:53:40.326 you'll see that we passed false on each of those, then yeah,
00:53:40.326 --> 00:53:43.280 price rules is enabled and then it will register it.
00:53:45.250 --> 00:53:47.700 But otherwise it'll skip that and keep on moving.
00:53:48.280 --> 00:53:48.940 Umm.
00:53:49.790 --> 00:53:50.630 And.
00:53:50.980 --> 00:53:52.600 Real quick, Brandon, can I ask you a question?
00:53:52.940 --> 00:53:53.390 Yeah, sure.
00:53:53.940 --> 00:53:57.659 Sorry for you answered this already, but can you tell me
00:53:57.659 --> 00:54:01.313 what the flat with store franchise or brand override is
00:54:01.170 --> 00:54:04.585 So yeah. Yeah. So that's a that's a specific pricing
00:54:01.313 --> 00:54:02.030 online 100?
00:54:04.585 --> 00:54:08.708 provider that allows the. So the products have a flat price and
00:54:08.708 --> 00:54:12.766 sort of talk about earlier where the product can be the actual
00:54:12.766 --> 00:54:16.760 record says price base and price sale and all that stuff. But
00:54:16.760 --> 00:54:20.561 then there is a feature or a set of features and stuff for
00:54:20.561 --> 00:54:24.620 stores, franchises and brands. It's kind of hard to explain in
00:54:24.620 --> 00:54:28.807 short terms what those are, but basically they're different ways
00:54:28.807 --> 00:54:29.580 of grouping.
00:54:30.730 --> 00:54:34.460 Data together on the site, so brands is typically associated
00:54:34.460 --> 00:54:38.191 with like multiple domains of a site. Stores is kind of like
00:54:38.191 --> 00:54:42.227 think of it I guess sort of like sellers on Amazon franchises. We
00:54:42.227 --> 00:54:46.079 only had one project that used it, but it's sort of similar to
00:54:46.079 --> 00:54:49.687 the stores, but it effectively allows those like UPS store
00:54:49.687 --> 00:54:53.662 franchise or brand to define the price of a product specifically
00:54:53.662 --> 00:54:56.780 within that store or that franchise or that brand.
00:54:57.410 --> 00:55:01.099 And that store franchiser brand price will override the price of
00:55:01.099 --> 00:55:04.675 the product. If you're shopping in that store franchiser brand
00:55:04.675 --> 00:55:08.193 and if it doesn't override that then it will fall back to the
00:55:08.193 --> 00:55:10.690 flat price specified on the product record.
00:55:11.450 --> 00:55:13.582 And I can give a quick explanation on the difference
00:55:13.582 --> 00:55:14.990 between store franchise and brand.
00:55:16.540 --> 00:55:17.030 Yeah.
00:55:18.080 --> 00:55:21.455 The brand is like the difference between Home Depot and Lowe's.
00:55:21.455 --> 00:55:24.302 They would have their own websites, but they might be
00:55:24.302 --> 00:55:27.782 selling a lot of the same stuff. They're both gonna sell hammers,
00:55:27.782 --> 00:55:30.629 but they might be selling hammers from different from
00:55:30.629 --> 00:55:32.000 different vendors such as.
00:55:32.660 --> 00:55:33.110 You know.
00:55:33.550 --> 00:55:37.711 Uh, Durabuilt and Ryobi or and and the Sears Craftsman lines of
00:55:37.711 --> 00:55:41.547 tools. They're gonna still they may have crossover of what
00:55:41.547 --> 00:55:45.577 they're gonna sell. They might have this different, different
00:55:45.577 --> 00:55:49.348 vendoring ones from those things, but the idea is that in
00:55:49.348 --> 00:55:53.053 Seth, that there are two separate websites that might be
00:55:53.053 --> 00:55:56.759 driven by the same database of data. They have their own
00:55:56.759 --> 00:56:00.920 identity and their own branding within their own marketplace of
00:56:00.920 --> 00:56:04.820 storefronts, like difference between Home Depot and Lowe's.
00:56:05.020 --> 00:56:08.706 But there be driven out the same physical catalog and there might
00:56:08.706 --> 00:56:12.279 be filters in those things that say that some of these products
00:56:12.279 --> 00:56:15.630 show up in this website versus this website. And that's the
00:56:15.630 --> 00:56:18.924 difference between brands. A franchise is to say that just
00:56:18.924 --> 00:56:22.554 like how you could go start your own franchise at McDonald's and
00:56:22.554 --> 00:56:25.737 you own that McDonald's storefront, you're still branded
00:56:25.737 --> 00:56:29.366 as McDonald's of that stuff. So in our case, like if there was a
00:56:29.366 --> 00:56:32.996 Home Depot that was a franchise of the main Home Depot like Home
00:56:32.996 --> 00:56:34.950 Depot, corporate versus franchise.
00:56:35.250 --> 00:56:38.092 The franchise might have their own website, the listener own
00:56:38.092 --> 00:56:40.747 stuff, but it's basically the Home Depot catalog. And so
00:56:40.747 --> 00:56:42.750 they're still driven up the same database.
00:56:43.470 --> 00:56:47.212 A store is a brick and mortar location of that actual, like a
00:56:47.212 --> 00:56:50.954 place in the physical world for where stuff is. So it's gonna
00:56:50.954 --> 00:56:54.515 have its own stock quantities. It's gonna have its own. It
00:56:54.515 --> 00:56:57.955 might have its own prices because they're running a sale
00:56:57.955 --> 00:57:01.697 to get rid of excess stock in that one location, that kind of
00:57:01.697 --> 00:57:05.137 thing. So that's what the physical stores come into play
00:57:05.137 --> 00:57:08.879 is what are those? The store might be underneath the umbrella
00:57:08.879 --> 00:57:12.259 of a brand or a franchise because that's who physically
00:57:12.259 --> 00:57:14.190 owns it. But the store is still.
00:57:14.290 --> 00:57:17.235 Physical place, whereas a franchise and a brand are both
00:57:17.235 --> 00:57:18.010 digital things.
00:57:21.550 --> 00:57:25.024 OK. That makes a lot of sense. What happens if there are? Is it
00:57:25.024 --> 00:57:28.118 possible for there to be multiple overrides like one for
00:57:28.118 --> 00:57:31.266 franchise and one for brand? And how do you determine the
00:57:31.266 --> 00:57:32.460 priority between them?
00:57:33.520 --> 00:57:37.738 The IT goes in the in the order of most specific and yes it they
00:57:37.738 --> 00:57:41.696 can. So basically the idea is the most specific level is the
00:57:41.696 --> 00:57:45.720 store, the next less specific level is the franchise and then
00:57:45.720 --> 00:57:49.678 the next specific level is the brand. And then after that it
00:57:49.678 --> 00:57:53.442 will go in that particular pricing provider where it does
00:57:53.442 --> 00:57:57.660 the overrides. If none of those three exist that is just use the
00:57:57.660 --> 00:58:01.488 value that's directly on the product. So if the hammer was
00:58:01.488 --> 00:58:03.110 499 base and there was a.
00:58:03.410 --> 00:58:06.395 The Home Depot wants to sell that for 699. That would
00:58:06.395 --> 00:58:09.987 override and if Lowe's wants to sell it for 5:49 then they would
00:58:09.987 --> 00:58:13.524 override and that's what it show up inside the Los websites. If
00:58:13.524 --> 00:58:17.006 there was a franchise of Home Depot that wanted to sell it for
00:58:17.006 --> 00:58:20.432 569, that's what would show up. And then if there was a store
00:58:20.432 --> 00:58:23.748 that had an excess number of these so they put them on sale
00:58:23.748 --> 00:58:27.064 for 20% off, they might. They might either do a discount to
00:58:27.064 --> 00:58:30.491 apply. That would only apply to the store for 20% off or they
00:58:30.491 --> 00:58:33.751 would just mark the price is different at whatever the 20%
00:58:33.751 --> 00:58:34.580 off amount was.
00:58:35.180 --> 00:58:38.063 So there's different ways they could physically do that. And
00:58:38.063 --> 00:58:40.946 then again, if there was no price defined otherwise, then it
00:58:40.946 --> 00:58:43.876 would just go, would it fall back to whatever the price is on
00:58:43.876 --> 00:58:46.900 the part of itself. And that's where the price rules and tiered
00:58:46.900 --> 00:58:49.972 pricing come into play for a lot of those more advanced types of
00:58:49.972 --> 00:58:52.855 scenarios is you're probably going to be using one of those.
00:58:52.855 --> 00:58:55.785 But we did have a client who wanted a very simplified version
00:58:55.785 --> 00:58:58.620 that basically said use whatever is in the product unless I
00:58:58.620 --> 00:59:01.030 specify otherwise with this very simple procedure.
00:59:01.760 --> 00:59:04.465 And so we we kept it around just in case anyone else ended up
00:59:04.465 --> 00:59:05.860 meeting to use it in the future.
00:59:08.980 --> 00:59:09.830 Gotcha. Thank you.
00:59:12.760 --> 00:59:13.530 Sweet.
00:59:14.110 --> 00:59:17.499 Umm. So yeah, I think hopefully that covers that and hopefully
00:59:17.499 --> 00:59:20.834 the general like provider. I know I'm going pretty high level
00:59:20.834 --> 00:59:24.116 in some of this stuff. I'm not really digging too far into a
00:59:24.116 --> 00:59:27.397 lot of it, but hopefully it's kind of giving you guys a good
00:59:27.397 --> 00:59:30.624 idea and a good example real quick while I'm thinking about
00:59:30.624 --> 00:59:31.700 it of more advanced.
00:59:31.780 --> 00:59:35.141 Uh config validation stuff is like in the payment providers.
00:59:35.141 --> 00:59:38.613 Most of these providers aren't valid, they're configuration is
00:59:38.613 --> 00:59:41.919 valid unless you're supplying all of the required ways. All
00:59:41.919 --> 00:59:45.114 the required properties to actually connect to their API.
00:59:45.114 --> 00:59:48.475 So for example, you'll see that on this orbital payment tech
00:59:48.475 --> 00:59:51.726 payment provider, if a client wants to use this, or if you
00:59:51.726 --> 00:59:55.253 want to enable this for your CEF setup, you need to add this to
00:59:55.253 --> 00:59:58.338 the enabled providers list, which is what this check is
00:59:58.338 --> 00:59:59.440 enabled method does.
01:00:00.140 --> 01:00:03.869 And you have to specify the username, password, merchant ID,
01:00:03.869 --> 01:00:05.580 test URL and production URL.
01:00:07.150 --> 01:00:09.661 In the settings and you can see the actual key for those is
01:00:09.661 --> 01:00:09.870 here.
01:00:10.710 --> 01:00:11.210 Umm.
01:00:12.430 --> 01:00:15.395 And so if you don't specify these, then it doesn't matter if
01:00:15.395 --> 01:00:18.215 you turn. If you add this to your enabled providers list,
01:00:18.215 --> 01:00:20.937 it's not going to enable it. It's not going to actually
01:00:20.937 --> 01:00:23.513 register it in the registry because you also need to
01:00:23.513 --> 01:00:26.478 register. You also need to set up all of the rest of the the
01:00:26.478 --> 01:00:29.297 required credentials for this provider to function in the
01:00:29.297 --> 01:00:29.880 first place.
01:00:30.690 --> 01:00:33.954 So this is a good place to check if you're like. Well, I thought
01:00:33.954 --> 01:00:36.865 I got everything, you know, I put in. I put this into the
01:00:36.865 --> 01:00:39.878 enable providers and I got my username and my password, but
01:00:39.878 --> 01:00:42.789 it's still not working. Well, this would be the very next
01:00:42.789 --> 01:00:45.852 thing you need to check, and honestly probably should be the
01:00:45.852 --> 01:00:48.914 first thing to check is what all do I need to supply to this
01:00:48.914 --> 01:00:52.027 provider for it to function for it to even register that it's
01:00:52.027 --> 01:00:55.290 that it should be used. So very good place to check is if you're
01:00:55.290 --> 01:00:58.001 ever not seeing a provider activate for one reason or
01:00:58.001 --> 01:01:00.210 another, check its config. Check what your.
01:01:00.520 --> 01:01:01.990 What you're forgetting to specify?
01:01:02.580 --> 01:01:06.684 Umm, because that's 90% of the time that's, that's why provider
01:01:06.684 --> 01:01:07.710 doesn't come up.
01:01:10.590 --> 01:01:14.316 So yeah, uh again, a lot of different types of providers in
01:01:14.316 --> 01:01:18.043 here feel free to explore a little bit on your locals. Take
01:01:18.043 --> 01:01:21.520 a look around. Familiar. Familiarize yourself with some
01:01:21.520 --> 01:01:25.122 of what's here, cuz you'll probably be thinking in seeing
01:01:25.122 --> 01:01:26.240 these quite a bit.
01:01:28.490 --> 01:01:29.710 And yeah.
01:01:30.040 --> 01:01:33.110 Umm. Let's see. One has any more questions? I'm gonna move on.
01:01:38.500 --> 01:01:39.270 All right.
01:01:41.010 --> 01:01:45.173 Alright, so 05 business logic. So we briefly mentioned
01:01:45.173 --> 01:01:50.017 workflows earlier when we were in the interfaces layer. This is
01:01:50.017 --> 01:01:54.558 the implementation of those interfaces here. So again a lot
01:01:54.558 --> 01:01:57.510 of it is autogenerated same as before.
01:01:59.130 --> 01:02:01.450 And you'll see that these dot generated files.
01:02:03.230 --> 01:02:06.678 But then let's see if I can find account contact extended. So
01:02:06.678 --> 01:02:10.071 when we looked at I account contact workflow over here we've
01:02:10.071 --> 01:02:13.575 got these three methods that we were looking at earlier in the
01:02:13.575 --> 01:02:16.522 interfaces. Here's the implementation of those right
01:02:16.522 --> 01:02:16.800 here.
01:02:18.440 --> 01:02:21.860 And so that's where a lot of this stuff happens.
01:02:24.040 --> 01:02:28.135 The workflow layer is where pretty much all of the non
01:02:28.135 --> 01:02:32.899 provider logic is implemented, so you're not gonna see business
01:02:32.899 --> 01:02:37.067 logic outside of this layer or potentially in providers
01:02:37.067 --> 01:02:41.906 depending on what it is because everything everything below this
01:02:41.906 --> 01:02:46.000 layer models and mapping them down is more relevant to
01:02:46.000 --> 01:02:46.670 defining.
01:02:47.600 --> 01:02:52.255 How these how the workflows will actually work and everything
01:02:52.255 --> 01:02:56.985 above this is more about the the actual service layer, the API
01:02:56.985 --> 01:03:01.040 layer if you will, and so generally speaking the vast
01:03:01.040 --> 01:03:05.920 majority 99.9% of your business logic will be in the 05 workflow
01:03:05.920 --> 01:03:06.520 project.
01:03:08.210 --> 01:03:12.151 So that being the case, if you're racking your brain trying
01:03:12.151 --> 01:03:16.092 to find where something is happening in the code, there's a
01:03:16.092 --> 01:03:19.836 pretty good chance it's happening somewhere in here. And
01:03:19.836 --> 01:03:20.690 so if you're.
01:03:21.290 --> 01:03:25.750 Having an issue with, I don't know something about.
01:03:27.330 --> 01:03:28.090 Let's find a good one.
01:03:28.890 --> 01:03:29.830 Uh.
01:03:31.150 --> 01:03:34.679 Sure, that works. You're having an issue with contacts, not, uh,
01:03:34.679 --> 01:03:38.099 doing something I don't know. Or client wants you to customize
01:03:38.099 --> 01:03:41.356 some behavior about contacts? Well, they're called context.
01:03:41.356 --> 01:03:44.613 It's probably under contacts, and then you've got a contact
01:03:44.613 --> 01:03:47.653 folder here for the actual contact table. Everything in
01:03:47.653 --> 01:03:50.965 here? It's probably gonna be relevant to what you're looking
01:03:50.965 --> 01:03:54.167 for. And here's your extended class so you can actually do
01:03:54.167 --> 01:03:55.850 your modifications now in here.
01:03:57.590 --> 01:03:59.000 Let's say that.
01:03:59.940 --> 01:04:00.210 Who?
01:04:00.980 --> 01:04:01.370 Sorry.
01:04:02.140 --> 01:04:05.461 I am just very tired today. Umm, let's say that you've got an
01:04:05.461 --> 01:04:08.620 issue with, I don't know upsert for one reason or another.
01:04:08.960 --> 01:04:12.190 Umm, uh. Whenever you're hitting the upstarted point, it's not
01:04:12.190 --> 01:04:15.112 behaving the way we expect. Well, here's your upsert end
01:04:15.112 --> 01:04:18.342 point. You can now do whatever it is you need to do with that.
01:04:18.342 --> 01:04:21.110 Or if a client wants to customize it for some reason.
01:04:23.340 --> 01:04:27.121 This is I mean it's named clearly and things are broken
01:04:27.121 --> 01:04:30.767 out clearly enough that generally speaking given some
01:04:30.767 --> 01:04:35.088 description of a bug, you should hopefully be able to find what
01:04:35.088 --> 01:04:36.370 you're looking for.
01:04:38.050 --> 01:04:41.104 There may be times where it's buried a few layers deeper than
01:04:41.104 --> 01:04:43.270 you would expect, and if you ever not sure.
01:04:45.010 --> 01:04:48.936 A. You can ask B. You can attach and step through until you find
01:04:48.936 --> 01:04:52.561 what you're looking for, but generally you should hopefully
01:04:52.561 --> 01:04:56.245 be able to at least sort of visually navigate without having
01:04:56.245 --> 01:04:58.540 to kind of resort to the brute force.
01:05:00.070 --> 01:05:03.120 Attaching and stepping through kind of method until you've
01:05:03.120 --> 01:05:05.600 exhausted just visually looking through things.
01:05:06.630 --> 01:05:07.140 Umm.
01:05:08.550 --> 01:05:11.532 So there's not a ton really to cover in here. That's the
01:05:11.532 --> 01:05:14.200 majority of what's what's happening in this layer.
01:05:16.040 --> 01:05:17.250 Just logic.
01:05:17.910 --> 01:05:20.810 Umm. So I'm gonna go ahead and move on from that one less
01:05:20.810 --> 01:05:22.860 anyone has any specific questions on it.
01:05:27.010 --> 01:05:29.240 And it sounds like a no.
01:05:28.850 --> 01:05:30.320 Silence is compliance.
01:05:31.050 --> 01:05:34.865 So alright, so the next layer is the services layer. So like I
01:05:34.865 --> 01:05:38.438 mentioned earlier above the business logic layer, we start
01:05:38.438 --> 01:05:41.769 getting into API stuff and specifically in the service
01:05:41.769 --> 01:05:45.160 project that is where we actually defined the endpoints
01:05:45.160 --> 01:05:48.672 the like the rest API that allows access to the back end.
01:05:48.672 --> 01:05:52.427 So I'm going to keep sticking with the count contacts because
01:05:52.427 --> 01:05:54.970 I've been doing that one this whole time.
01:05:57.090 --> 01:06:01.351 So here's a handful of end points and you can see that we
01:06:01.351 --> 01:06:05.980 use a middleware called service stack as our basically our API
01:06:05.980 --> 01:06:06.420 layer.
01:06:07.720 --> 01:06:12.170 And the way that you define endpoints in service stack looks
01:06:12.170 --> 01:06:16.838 like this. You define a class. That class represents what comes
01:06:16.838 --> 01:06:18.370 in and what goes out.
01:06:19.610 --> 01:06:23.985 For any given endpoint. But the way that you define what comes
01:06:23.985 --> 01:06:28.428 in is by defining the members of that class and decorating them
01:06:28.428 --> 01:06:32.803 with some attributes. The way to find what goes out is this. I
01:06:32.803 --> 01:06:37.177 return attribute so this is an endpoint that accepts an ID and
01:06:37.177 --> 01:06:41.690 that ID actually comes from the path right here and it returns a
01:06:41.690 --> 01:06:46.064 SEV action response, so it the body, the response body will be
01:06:46.064 --> 01:06:48.980 a SEV action response. Keep in mind that.
01:06:49.390 --> 01:06:52.573 Nothing actually absolutely validates or forces that you
01:06:52.573 --> 01:06:56.147 return a CEF action response on this. You could return nothing.
01:06:56.147 --> 01:06:59.497 If you wanted, you could return anything else. However, you
01:06:59.497 --> 01:07:02.959 should always return what you say you're gonna return because
01:07:02.959 --> 01:07:06.086 we also use this I return attribute on the front end so
01:07:06.086 --> 01:07:09.604 that it knows what return type it should expect so it can work
01:07:09.604 --> 01:07:10.050 with it.
01:07:10.910 --> 01:07:13.180 Emphasize could versus should.
01:07:11.130 --> 01:07:11.540 So.
01:07:13.470 --> 01:07:17.421 Yeah, yeah, you you could do that, but it will probably get
01:07:17.421 --> 01:07:20.910 you a comment on your PR that you'll have to fix so.
01:07:21.390 --> 01:07:24.998 Umm I I will say though that I have accidentally returned the
01:07:24.998 --> 01:07:28.781 wrong type where maybe I copied and endpoint just to to make one
01:07:28.781 --> 01:07:32.505 really quickly and I forgot to change the I return or I changed
01:07:32.505 --> 01:07:35.822 the implementation of some custom logic for a client and
01:07:35.822 --> 01:07:39.255 forgot to change what the I changed what like the workflow
01:07:39.255 --> 01:07:43.037 returns but forgot to change the I return on the on the endpoint
01:07:43.037 --> 01:07:44.550 that happens sometimes so.
01:07:45.740 --> 01:07:48.990 It's it's fine if you forget as long as you know we change it at
01:07:48.990 --> 01:07:50.590 some point or, you know, fix it.
01:07:50.740 --> 01:07:54.874 Umm. And you know, just try to keep in mind that changes like
01:07:54.874 --> 01:07:59.207 that do bubble up and to try to be Cognizant and make the change
01:07:59.207 --> 01:08:03.340 everywhere that's relevant. So let's see if I can find a more
01:08:03.340 --> 01:08:06.140 complex endpoint than these ones there's.
01:08:07.790 --> 01:08:11.494 Probably some in here. Yeah. Perfect. OK, so here's an
01:08:11.494 --> 01:08:12.100 endpoint.
01:08:13.500 --> 01:08:16.437 That I'm not gonna work too much about what it actually does, but
01:08:16.437 --> 01:08:17.950 you can see that it actually has.
01:08:20.060 --> 01:08:22.730 Uh Members in the body of here.
01:08:24.170 --> 01:08:27.400 And it's the attribute name and attribute value.
01:08:28.570 --> 01:08:31.432 And these are both query parameters. So for example, if
01:08:31.432 --> 01:08:34.650 you were hitting this endpoint, you'd hit your I your uh, your
01:08:34.650 --> 01:08:35.110 API path?
01:08:36.920 --> 01:08:39.030 And I'm going to have to make my text in here larger.
01:08:43.550 --> 01:08:45.280 So you hit this, you know your.
01:08:46.100 --> 01:08:47.670 Path to API will be over here.
01:08:49.400 --> 01:08:54.270 Umm. And then I wanna find 1 where the attribute name.
01:08:55.830 --> 01:09:00.890 Is high and the attribute value equals hello. So if I were to
01:09:00.890 --> 01:09:05.379 send this as a get request to the API, then that would
01:09:05.379 --> 01:09:10.684 actually map to these properties on this specific request and to
01:09:10.684 --> 01:09:15.336 define what happens when somebody hits this route on the
01:09:15.336 --> 01:09:17.050 API as a get request.
01:09:17.670 --> 01:09:21.090 Uh, these service classes have methods.
01:09:22.070 --> 01:09:25.991 This method is called get and it accepts this object. So this is
01:09:25.991 --> 01:09:29.912 the method that will get called when somebody hits this route as
01:09:29.912 --> 01:09:33.471 a get request. It calls this method and what a convenience
01:09:33.471 --> 01:09:36.970 you have an instance of this object that contains all the
01:09:36.970 --> 01:09:40.830 properties that were passed in on these query parameters. So if
01:09:40.830 --> 01:09:44.269 I were to hit this exact endpoint exactly like this then
01:09:44.269 --> 01:09:48.008 I was attached. I would hit this breakpoint and the values on
01:09:48.008 --> 01:09:51.809 request attribute name would be high and attribute value would
01:09:51.809 --> 01:09:53.980 be hello exactly as I sent them on.
01:09:54.060 --> 01:09:54.930 Micro parameters.
01:09:55.920 --> 01:09:59.284 Umm, so, uh, another quick thing that I'll cover here is
01:09:59.284 --> 01:10:02.885 obviously get requests are one of the many kinds of requests
01:10:02.885 --> 01:10:06.485 you can make. If this was a post request then you can change
01:10:06.485 --> 01:10:10.144 these parameter types to body and they'll actually be part of
01:10:10.144 --> 01:10:13.862 the body of they'll have to come in as the body of the request
01:10:13.862 --> 01:10:17.522 rather than on the query string. And so that's how you handle
01:10:17.522 --> 01:10:21.240 things like that by default if you don't specify, I believe it
01:10:21.240 --> 01:10:25.076 defaults to query string on get requests and defaults to body on
01:10:25.076 --> 01:10:25.430 posts.
01:10:25.850 --> 01:10:29.547 But most of the time it's best to specify, uh, the API member
01:10:27.070 --> 01:10:27.820 And it's correct.
01:10:29.547 --> 01:10:33.244 attribute so you can decorate if it's. If it's required, what
01:10:33.244 --> 01:10:36.881 what data type it is, the place that the parameter is coming
01:10:36.881 --> 01:10:40.816 from, all that kind of stuff. So specify in the general case, but
01:10:40.816 --> 01:10:44.036 if you're just testing something, throwing together a
01:10:44.036 --> 01:10:47.673 quick endpoint, whatever it is, it does have pretty sensible
01:10:47.673 --> 01:10:49.700 defaults that you can rely on so.
01:10:50.490 --> 01:10:50.970 Umm.
01:10:52.500 --> 01:10:53.410 Uh, yeah, so.
01:10:54.610 --> 01:10:58.860 This is another thing that I'll really quickly show people of.
01:10:59.380 --> 01:11:00.190 Umm.
01:11:01.800 --> 01:11:05.229 I'm going to just refresh this page and OK, perfect. So I'll
01:11:05.229 --> 01:11:08.825 switch to Effexor XR. So you can actually see the requests that
01:11:08.825 --> 01:11:12.197 are being made. So these are actually requests to this back
01:11:12.197 --> 01:11:15.457 end. Let's say that you're working on a site and for some
01:11:15.457 --> 01:11:15.850 reason.
01:11:16.990 --> 01:11:20.264 Book calculate inventory is throwing an error for some
01:11:20.264 --> 01:11:23.716 reason. You're getting a 400 back on this endpoint you're
01:11:23.716 --> 01:11:27.346 like. Well, I mean, I don't really know where to start. I've
01:11:27.346 --> 01:11:31.215 never worked on that before. No problem. You can mouse over that
01:11:31.215 --> 01:11:35.024 and look at everything after API storefront so you can see it's
01:11:35.024 --> 01:11:38.535 probably really small, but you can see after that is slash
01:11:37.900 --> 01:11:41.618 You either Scroll down or pause the video so that it can keep up
01:11:38.535 --> 01:11:39.130 providers.
01:11:41.618 --> 01:11:44.420 with the thing. Otherwise it keeps going blurry.
01:11:46.260 --> 01:11:46.900 Ohh did it.
01:11:47.610 --> 01:11:48.680 Yeah. Hold on. Let me.
01:11:50.870 --> 01:11:52.140 Just kill it.
01:11:51.030 --> 01:11:53.690 That he blurred out for a minute in a screen capture.
01:11:52.960 --> 01:11:56.005 Yeah, sorry about that. Alright. Uh, tell me when it gets sharp
01:11:56.005 --> 01:11:56.290 again.
01:11:57.410 --> 01:11:57.810 Again.
01:11:58.440 --> 01:12:01.959 OK. But if you mouse over these or you can click on them and go
01:12:01.959 --> 01:12:05.367 to the headers section, you'll see the request URL over here.
01:12:05.367 --> 01:12:08.995 And like I said, that's probably really small, so I'll copy paste
01:12:08.995 --> 01:12:12.459 that into this larger screen so you can see this is the actual
01:12:12.459 --> 01:12:15.867 path that that request was sent to. So let's say that I got a
01:12:15.867 --> 01:12:19.330 400 on this and I wasn't sure how to debug it. Well, this is a
01:12:19.330 --> 01:12:22.684 good place to start. Obviously if this is throwing an error,
01:12:22.684 --> 01:12:26.092 then something in this code path is wrong or whatever. And So
01:12:26.092 --> 01:12:29.501 what you wanna do is you can look at this and then everything
01:12:29.501 --> 01:12:30.050 after API.
01:12:30.130 --> 01:12:33.967 Storefront or if it's in your admin, it's going to be API
01:12:33.967 --> 01:12:37.805 admin, but this will be the actual path you want. This is
01:12:37.805 --> 01:12:42.039 what's gonna be defined in that route attribute on the back end
01:12:42.039 --> 01:12:45.942 so you can grab that little section here. Go into the back
01:12:45.942 --> 01:12:49.911 end control shift F is the Visual Studio shortcut for find.
01:12:49.911 --> 01:12:53.947 You can paste that there, look in the entire solution and CS
01:12:53.947 --> 01:12:57.916 files and find all and what do you know there it is. So now
01:12:57.916 --> 01:12:59.570 I've found this endpoint.
01:13:00.480 --> 01:13:03.756 I found the actual class that describes the endpoint, at least
01:13:03.756 --> 01:13:06.771 from here you can find the implementation by. I know some
01:13:06.771 --> 01:13:10.047 people don't have this little code lens thing on. I like it. I
01:13:10.047 --> 01:13:13.270 keep it on, but if you don't, you can just right click it and
01:13:13.270 --> 01:13:16.337 find all references wherever that is where it is, and then
01:13:16.337 --> 01:13:19.561 you'll see one that says like public async task. In this case
01:13:19.561 --> 01:13:22.680 it's post because it's a post request. Double click on that
01:13:22.680 --> 01:13:25.852 and here you go. Here's right where you put your break point
01:13:25.852 --> 01:13:29.075 to start debugging that problem. You can then debug attach to
01:13:29.075 --> 01:13:32.247 process, blah blah blah. There's guides in nuclino on how to
01:13:32.247 --> 01:13:33.650 attach and debug and stuff.
01:13:35.040 --> 01:13:38.550 But that will that will give you your first starting point on.
01:13:39.370 --> 01:13:42.262 Debugging some issue with this bolt, calculate inventory
01:13:42.262 --> 01:13:44.950 request or whatever other request you want to debug.
01:13:44.950 --> 01:13:47.790 That'll lead you pretty much right to a starting point.
01:13:48.360 --> 01:13:50.190 Umm and often.
01:13:51.290 --> 01:13:54.463 Often the error message you'll get back on this endpoint. So
01:13:54.463 --> 01:13:57.843 let's say that you you got a 400 on this. You can go look at the
01:13:57.843 --> 01:14:01.171 preview and it'll give you some snippet of an error message and
01:14:01.171 --> 01:14:04.499 you might also get a log ID and if that's the case then you can
01:14:04.499 --> 01:14:07.880 go consult the system log table in the database and see maybe if
01:14:07.880 --> 01:14:11.052 there's a good error message and then you don't even have to
01:14:11.052 --> 01:14:13.600 attach it will just tell you what's wrong maybe.
01:14:14.070 --> 01:14:18.702 Umm and you know, save yourself some time. But assuming you've
01:14:18.702 --> 01:14:22.598 already exhausted the easy routes, the possible easy
01:14:22.598 --> 01:14:27.450 answers to the problem that is a good way to find where to attach
01:14:27.450 --> 01:14:29.140 for any given endpoint.
01:14:30.370 --> 01:14:33.160 Umm. And we're pretty much at the bottom of the of the things
01:14:33.160 --> 01:14:35.860 that you're really gonna be working with on the day-to-day.
01:14:37.080 --> 01:14:40.325 So I mean, there's a lot of other layers in here, but the
01:14:40.325 --> 01:14:43.850 there's 10 testing is all the unit tests you'll work with this
01:14:43.850 --> 01:14:47.374 if you add new schema or if you wanna build new unit tests for
01:14:47.374 --> 01:14:50.395 new logic that you've constructed 07 portals is where
01:14:50.395 --> 01:14:51.010 the actual.
01:14:52.200 --> 01:14:55.118 Different uh, like API layers are defined. I've got some of
01:14:55.118 --> 01:14:58.133 them unloaded locally because I'm just, I'm not using them so
01:14:58.133 --> 01:14:59.300 saves time on the build.
01:15:00.700 --> 01:15:01.090 But.
01:15:02.880 --> 01:15:06.183 Yeah, that's. I think that pretty much covers it with with
01:15:06.183 --> 01:15:07.190 four minutes left.
01:15:07.490 --> 01:15:11.844 And so I know that I I like rocketed through the majority of
01:15:11.844 --> 01:15:16.554 that, and it's probably a ton of information overload, but I hope
01:15:16.554 --> 01:15:19.980 you guys are able to get something out of that.
01:15:21.360 --> 01:15:26.120 And for those of you that I have more shadowing sessions with.
01:15:28.000 --> 01:15:32.441 Feel free to poke around in here and, you know, do whatever it is
01:15:32.441 --> 01:15:36.544 you feel like you wanna do to get familiar with this. And if
01:15:36.544 --> 01:15:40.514 you want to use those shadowing sessions to just ask every
01:15:40.514 --> 01:15:42.330 question, you can think of.
01:15:43.470 --> 01:15:47.280 I am more than happy to answer those questions, so otherwise we
01:15:47.280 --> 01:15:50.672 can do as we've done in the other shadowing sessions and
01:15:50.672 --> 01:15:54.303 I'll just work on some stuff and you can watch as I toil and
01:15:54.303 --> 01:15:54.660 paint.
01:15:55.180 --> 01:15:56.410 Umm but.
01:15:57.620 --> 01:16:00.240 Uh, yeah. So any other questions on anything else?
01:16:05.770 --> 01:16:07.640 Sounds like a no.
01:16:08.670 --> 01:16:10.530 Yeah. Thanks a lot, Brendan. That was really helpful.
01:16:11.030 --> 01:16:11.710 And no problem.
01:16:11.610 --> 01:16:12.680 Yep. Thank you.
01:16:13.410 --> 01:16:14.520 Yeah. Thank you very much.
01:16:14.880 --> 01:16:18.518 No problem at all and it is coming up on 4:00 o'clock. I
01:16:15.640 --> 01:16:16.080 Share it.
01:16:18.518 --> 01:16:22.412 can't believe I like, nailed the time on that. That's pretty
01:16:22.412 --> 01:16:25.220 sick. No way. I and only I run out of time.
01:16:26.600 --> 01:16:30.571 But anyway, well, if nobody has any more questions, then I think
01:16:30.571 --> 01:16:34.419 we're probably all good to drop. So you'll have a good weekend
01:16:34.419 --> 01:16:36.740 and I will talk to you all next week.
01:16:38.310 --> 01:16:41.409 Yeah. And for you guys that I haven't met, it's good to meet
01:16:39.420 --> 01:16:39.930 Thanks.
01:16:41.409 --> 01:16:43.440 you guys and we will see you next week.
01:16:45.150 --> 01:16:45.710 Alright.
01:16:45.470 --> 01:16:47.270 Yeah. Good to meet you too. Have a good weekend, guys.
01:16:48.710 --> 01:16:49.680 Thanks. Have a good weekend.
01:16:49.090 --> 01:16:49.550 Deal.
01:16:50.550 --> 01:16:51.620 Then we can see you.
01:16:52.170 --> 01:16:53.100 Yep, have a good one.