The Modern .NET Show

Episode 84 - ASP .NET Core 5 Design Patterns With Carl-Hugo Marcotte

Embedded Player

Episode 84 - ASP .NET Core 5 Design Patterns With Carl-Hugo Marcotte
The .NET Core Podcast

Episode 84 - ASP .NET Core 5 Design Patterns With Carl-Hugo Marcotte

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Transcription

Hello everyone and welcome to THE .NET Core Podcast. An award-winning podcast where we reach into the core of the .NET technology stack and, with the help of the .NET community, present you with the information that you need in order to grok the many moving parts of one of the biggest cross-platform, multi-application frameworks on the planet.

I am your host, Jamie “GaProgMan” Taylor. In this episode I talked with Carl-Hugo about design patterns, some of the interesting changes which are coming in .NET 6 (especially those which are designed to take some of the ceremony away from developing with .NET), and his book An Atypical ASP .NET Core 5 Design Patterns Guide.

Along the way we discussed the benefits of both Vertical Slice Architecture and Event-Driven Architecture, including the ability to simplify a solution down to the data contract, and taking away some of the complexity in tightly-coupling two services together.

So let’s sit back, open up a terminal, type in dotnet new podcast and let the show begin.

The following is a machine transcription, as such there may be subtle errors. If you would like to help to fix this transcription, please see this GitHub repository

Jamie

So first thing I want to say Carl-Hugo is, thank you ever so much for being on the show. I really appreciate it. A) because you’re a very busy gentleman, and we’re all really busy anyway. And B) because you know, I’m on the other side of the planet to you. So thank you for clearing some time to talk with me.

Carl-Hugo

Well, thank you for having me.

Jamie

You’re very welcome. You’re very welcome. So I thought before we get on to today’s topic, I was wondering, would you mind letting the listeners know a little bit about you? I know, off air we talked about how, you know, titles can be a little bit difficult and describing yourself can be difficult, I appreciate that. If you have any words, then you know, they would be it might be useful for this in this day. To hear them words describing yourself. If you don’t, then that’s also fine, too.

Carl-Hugo

Yes, well, I definitely don’t don’t like all titles and, and labels and such. But well, let’s say to play a bit with the book title, I do have an atypical career path. So I started coding when I was a kid. Just transcribing so some some listing from my cocoa too. I learned some basic, then the hack together some web pages and the 90s. And some point, went back to school, learn the web development ASP, ASP .NET, worked a few years is a firm, did the Bachelor Degree in parallel work while working. Then became a freelancer and now senior solutions architect, which is my official title. So I did a lot of, I had the opportunity to do a lot of design and development during my career.

Jamie

That’s cool. I’m always interested to talk to people, regardless of where they are on the career path, right? Because the way I see is we all have different experiences. And we all took different paths. And someone who is really far along in their career, can also take lessons from someone who’s at the beginning of their career, right? Because the way that I tackle a problem may be different to the way that you tackle a problem. And so I mean,I’m nowhere near as advanced or professional as you are going to go but you know, I’m getting there.

Carl-Hugo

Well, I’d say I’d like to add on this. This is very true. And that’s the thing you have to to listen to everybody like not just like, the so called experts or whatnot, like the beginners and I saw, like in recent project, I had a lot of interns, and some of them, like were very proactive when bringing ideas forward. And we ended up making a better design, because, well, we listened to their ideas, and they had great ideas. As you said, I mean, everybody can bring something.

Jamie

Absolutely, absolutely. And yeah, like I say, I feel like everyone can bring something, regardless of where they are in their career path. You know, I’ve always been the person who will put their hand in the air and say, “look, okay, I feel like someone’s making assumptions here. Because I don’t know the answer to this question. But you all seem to know the answer. So could you sort of tell me what the answer to this question is, and then I’ll understand why we’re going in this direction.” And what I found is nine times out of 10, when I asked that, “hey, what does this mean? Because I don’t understand it. And I feel like an assumption has been made.” No one knows what it sounds like. No one knows what it means. And so I feel like it’s important to be brave enough to ask that question. And I found that sometimes, it’s the juniors, who will ask that question. “Hey, I’ve never touched this technology before. I’ve never worked with this technology before. For instance, why are we doing a jwt instead of a cookie?” Right? Cookies exist for a reason, cookies have existed for forever. And we can do auth perfectly with a cookie, why are we doing that versus jwt? And that gives you a chance to sort of answer the question of, “well, okay, so jwt’s are sort of more of a modern practice that requires a little bit more effort. But it can, not always, but it can be a little more secure. So let’s do that instead.” And then you kind of go down that route of explaining something but then, you know, just because you are and I’m not saying this about you Carl-Hugo but just because you are a senior on the team, doesn’t then necessarily mean that you know all the answers, right?

Carl-Hugo

Well, actually, I’d even add to that. Being a senior don’t make you have all the answers. Nobody does.

Jamie

Yeah, I think you’re right. Just because you’re a senior doesn’t mean you know the answers, right.

So like, for instance, I have absolutely no experience with Vue js. This is a rather trivial example, but I have no experience with Vue js. But I’ve been playing with web technologies now for 10, 11, 12 years. So somebody comes to me and says, “how do you do this in Vue JS?” I’m gonna parrot the question right back at them, “I don’t know, how do you do that in Vue js?” right. And that could be a junior in that they “only” - I hope you can hear the body quotes - they “only” have a year, two years of experience. But maybe that year or two years is entirely in Vue. js? Well, they’re the expert, right? Just because I’m a senior person, just because I have more years of experience doesn’t mean that my experience is somehow better, or more detailed or anything.

And I genuinely feel like the best way to work as a team, when you’re in development is to be a team, right? Yeah, someone’s going to lead it, but everyone’s got to help out in every which way they can. And everyone’s opinions matter.

Carl-Hugo

Well, exactly. And someone needs to lead that. But leaders are not like dictators. I mean, a good leader will empower their teammates with knowledge, like. And I’m pretty sure that even if you never did any Vue JS, with all the experience you have in web technology, you can contribute to a web project using Vue js. You might not programme it, because it’s not something you know, you may want to learn it, but I’m sure that you’ll find some kind of way to contribute to that project. Because you take knowledge and you can apply it to a different technology. That’s all web. So there’s some similarities somewhere.

Jamie

Absolutely, absolutely. And it’s all JavaScript. So at some point, it’s got to run in JavaScript land. And so there’s only so many ways you can write JavaScript syntactically. Yeah, it all makes sense at that point is just, “which command is it?” Because it’s the same language, right, so, “which command is it to do an HTTP request? Oh, it’s like this. Okay, brilliant. Okay, I’ll do that.” Or, “which command? Is it to update the model? Oh, well, it’s like that. That’s that’s different to react, which is different to Angular. Oh, brilliant. Okay, I’ll just do that.” You know?

Carl-Hugo

Yeah. And even, even more then that. Like, they’re all over HTTP. So if you know, HTTP, you know, it’s pretty simple. Like there’s headers, and there’s a body. And you see, you talked about cookies? Well, cookies are just one header. So when you start to pile up those skills or that knowledge, well, whatever the technology you’re using, you can leverage that because technology often makes those kind of thing like magical. So it’s magically doing the work for you. But if you do get what the magic is, that can often help you whatever the tech stack you’re using.

Jamie

Absolutely. I always explain to people that is like, once you’ve gotten to the point where you understand the level of where that technology sits in that stack. Let’s say you’re doing JavaScript, right? You understand how the JavaScript stuff is working, like you said, go learn HTTP, or go learn how the DOM works, or go learn how the JavaScript engine hooks into the browser. And with that sort of underlying knowledge, just as you said, you can understand the thing that you are working with a little better, I feel.

Carl-Hugo

Yep, totally true. I agree with you. Well said.

Jamie

Thank you very much. I don’t think it was well said, because I said it. But that’s just my self deprecating, I was gonna say “humour”. We’ll put that in bunny quotes, that’s what we’ll do.

Carl-Hugo

That’s perfect. I like it.

Jamie

So one of the things that we’re here to talk about today Carl-Hugo is the book that you’ve written. So this is book, I’ll let you describe it in a moment. But the the title has a it’s a bit of a long title, and it’s an it’s “An A typical ASP .NET Core Five Design Patterns Guide”. So I was wondering, could you give us a an elevator pitch for the book and maybe talk about that title a little bit. I know that, you know, I wasn’t expecting to see the word atypical in in a book about design patterns, right?

Carl-Hugo

Yes, certainly, I’ll try to be concise here. But like the book is pretty huge. So there’s a lot to describe, like it’s over 700 pages. My goal was to take the readers into a journey to explore like architectural techniques and principles. Not just design patterns or not just the Gang of Four design patterns, like most of the design pattern books that I’ve bought, like, they are basically the Gang of Four patterns but oriented with some technology. I do have some really good design pattern books that talks about golf, don’t get me wrong here. But this is not what I wanted to do. So I’m taking the reader through a series of subjects from some Gang of Four patterns, but I explore and re-explore them.

So for example, I focus a lot of dependency injection and I take some of those patterns, show the original way of putting them, and then I tried to revisit them using dependency injection, as a strong base to do DI [dependency injection]. I also explore different possibilities inside techniques or tricks that I tried to put here, there based on my experience. And I tried to have the reader understand and think design, not the learn magic recipies. It’s really, “here’s how it works.” And I’m trying to do that by bringing the reader inside code, like, “here’s why.” And there’s a lot of step by steps. There’s standalone chapters, but there’s many chapters that are also kind of linked. So when you go through the book, like certain chapter one after the other, you get that journey, like from, “okay, we start somewhere, then we reach that end goal there.” And hopefully, that’s where you understand that the thinking, like the thinking way behind the pattern, if this makes sense.

Jamie

Yeah, that totally makes sense. I’ve read, like you said, you know, similarly, I’ve read design pattern books that are quite literally, “here are each of the Gang of Four design patterns, but in C” or in Visual Basic or in JavaScript. And there’s nothing wrong with them, but they are - and I’m going to throw a bunch of quotes around this - “just” regurgitating that information without any kind of explanation as to why we’re doing it or why we’re learning it. But I think that having read your book, Carl-Hugo, I felt like there was a lot of, “okay, so here’s a problem. And here are some solutions. And here is a widely accepted pattern for solving that, that problem. Let’s implement that pattern or whatever. And see where we end up.” And like you say, you know, the one chapter leads directly into the next.

There’s a chapter where you talk about the mediator pattern, and then using Mediatr, right, the library, and then the next chapter is, “so now that we know what mediator is, let’s see how we can use that in conjunction with…” Yeah, and I felt that was, that feels to me more like, “let’s build on this knowledge, almost like, let’s take a course,” right? Because when you take a course you don’t learn things by themselves, you don’t learn stand alone bits of information, you learn this bit information, and then the next piece hooks into this previous piece of information and makes your understanding better as a whole. Right?

Carl-Hugo

Yes, true. And this is also something that I tried to bring forward is: mix patterns. Because patterns are often seen as kind of, from a beginner’s standpoint, it’s like an esoteric kind of thing that is unreachable. But actually, there are just a bunch of simple techniques that when you know, you can put together and use them. They are not like rules or laws or whatnot. It’s just a bunch of tools that you have to learn and when you know, well it’s just easier; like your life will just become easier afterward. So that’s really what I tried to put together like, in that journey, like, “let’s learn the tools and let’s mix them.” Because that’s also that I received and that I had myself when I was at that point in life to learn design patterns;like you learn all of those little things independently. But how do you put them together? So this is the hard part, like, using one skill to do something else. This is very hard in life. And this is what I tried to bring to the reader in, in the book.

Jamie

Sure, and yeah, as someone who was reading through it - so full disclosure, I’ve read Carl-Hugo’s book - I really appreciated that. He was all sort of hooked together.

But I guess one thing that listeners may be wondering is, you know, the title says, ASP .NET Core Five, right, or ASP .NET Core, right? Do I need to know ASP .NET Core to be able to get anything out of the book? And if I do, do I need to know, a huge amount? So let’s say I’m working in enterprise and I haven’t had the chance to build anything in the .NET Core or .NET Five technology stack yet. I’m working in .NET Framework 4.6. Is there a huge amount of stuff in there that’s required? Like do I need to know lots of background knowledge about how .NET Core, .NET Five, ASP .NET Core is, sort of glued together? Or is it more a case of, “that’s cool, as long as you know, a little bit of .NET you carry on”?

Carl-Hugo

Well, if you know dotnet, core, or ASP. NET Core, it will help you a lot. That said, I do cover many 100 Dory topic. But this is in no way like a step by step. Let’s learn ASP. NET Core. If you’re a seasoned ASP. NET developer, like with dotnet framework, you’ll most likely be able to catch up maybe read some intro tutorial beforehand, or go hand in hand with reading the book and running a bit on the side for the differences. But I’d recommend you to have a good C sharp knowledge or dotnet knowledge, I believe that that will help you get the most out of it.

Jamie

Makes sense, right? If the book title was learn mediaeval pottery practices in French, I need to know French before I can learn the mediaeval pottery practices, right? I need to know a little bit about it. So that totally makes sense. So yeah, if you’ve got a better dotnet, you can follow along. That makes sense?

Carl-Hugo

Yes. Well, it is an intermediate level book. So I like design patterns are not like beginner levels. So the book expects you to to, to have a certain knowledge. But But again, I do cover a few introductory topics together to help the reader. So somebody from dotnet framework should guide easily pick it up. It’s not like a step by step. Let’s learn of course.

Jamie

And like I said, that makes sense. Right? So here’s the thing, right? we’ve, we’ve talked about design patterns a lot so far. And my personal opinion is that design patterns and the solid principles sort of go really well together. You know, one, like the design patterns, show off some of the really good points about solid and solid itself, the principles of solid all together, show off why perhaps you should use certain design bands. That’s my opinion. I know everybody’s got their own opinion. You know, how do you how do you feel about that? Do you feel like solid and design principles go together? And if so, do you cover that kind of idea in the book? For some people it might be a case of I don’t even know what solid is you’re saying that this is a book aimed at intermediate level developers. They may you know, if you’ve not heard of design patterns, you may not have heard of solid and that is perfectly fine.

Carl-Hugo

Yes, well, I explained the solid principle I use simple but concise language. So you get the pattern, you get the principles, and you can learn them while not having to bother over like overly complex language. I think simple as is worth a lot evident in software engineering, especially in software engineering. Simple is often the gold But yeah, so I do talk a lot about them. And the solid principles are for those who don’t know, our guiding our five guiding principles that basically it’s called loose coupling. So basically solid is loose, loose coupling. And there are ways to to help you achieve that. You said you, you you like solid principles I like the solid principles do. What is important is they are not laws, they’re just principles. And I try also to hammer that in the book. Because there’s some people that really don’t like them. But probably, like a lot of examples that I sighs is because some people do think there are laws. And if you apply the solid principle everywhere to the more, the more than you can, you may end up with troubles, or your project may cost more to develop for unneeded flexibility. Like I love flexibility, but sometimes you don’t need flexibility. So during those time, you can say, Okay, I’m knowledgeable enough to say, we won’t apply this principle here, because we don’t need that level of flexibility. The drawbacks are, okay. So this is also what is important in in this, and this is how I tried to approach it as much as possible. And throughout the book, I tried to reference the solid principles and, and make parallel with the pattern we’re using to the principles and show the readers like what this pattern bring forward. And sometimes there’s some negative, right. But often, there’s a lot of positive that the pattern bring. And I tried to I position the pattern compared to the solid principle, a lot to help understand them.

Jamie

I like that, because a lot of the time, you know, like you said, they’re principles, they’re not laws, they’re not required. It’s guiding advice that there has been proven over time to aid in building software that is loosely coupled, that is easier to maintain. I mean, you don’t, you can still make code that is loosely coupled and easy to maintain without following any of the solid principles. And that’s perfectly fine. But if you follow these principles, it’s a sort of a shortcut to making your code loosely coupled and easier to maintain and testable and all of the other things that that solid aims to achieve. And the same thing with design patterns, right? As as wonderful as design patterns are, you don’t have to use them. And even if you do, you don’t have to use them absolutely everywhere, right? So like a builder pattern would likely be useless in in a function that is meant to take 1000 maybe 100,000 HTTP calls every second, and just poke at the database and say, is this is this record present or something? Yeah. So I sometimes feel like design patterns and solid can be used to over engineer some things. Sometimes, yes, or definitely is a context specific thing, right. And so if the context in which you are building, you’re building a micro service, and it will take one message in and it just goes poke, poke at something else, you may not need any design patterns. But if you’re building a multi tiered, monolithic application that does a whole bunch of stuff. Yeah, maybe.

Carl-Hugo

Yes. Well, I totally agree with with you there. And what there’s two thing I’d add there first, solid, solid, it’s good, like the solid principles are good for code. But they’re also good at higher level design. Like when you design an app or microservices system, like the single responsibility principle does apply to your micro service or does apply to a layer it does apply to whatever unit we’re talking about when you’re designing. So they can be seen or used only for, for what most people use them or their ride ridden for. So code and smaller level things, but you can you can use them for pretty much everything and they apply. And as for the design patterns like often you I’m pretty sure that before learning about design patterns, like you have done stuff that were actually design pattern, but you didn’t know the name. And, and vice versa, like so. So So yeah, so basically patterns are our name technique, learning me are great because well, if you don’t think about it, then you know the pattern, you can apply it. But often, you’ll just do it without even knowing, like strategy. That’s I think the easiest one strategy pattern is something that they have. And if you don’t know this pattern, you go to a cue ASP. NET Core tutorial. With dependency injection, you’ll use the strategy pattern, and we’ll just not know about it.

Jamie

Anything, that’s what I really like about dotnet core slash dotnet, five, slash dotnet. Six, and ASP. NET Core is that it has been rebuilt from the ground up with these design patterns in mind, you know, that’s not to say that dotnet framework didn’t have these design patterns in mind. But things like like you say, strategy button, and especially dependency injection, and things like just so much simpler now, because they built in, right, and like you say, you’re using it without realising you’re using the builder pattern. I believe it’s the builder pattern, or as the Options button when you’re when you’re building up the options for your HTTP handlers, when you do like add MVC, and then you can just, you can build a response there, and then in the startup class, without actually having any controllers. And and all of these patterns are just there is almost I mean, it isn’t exactly that. But this is almost Aspect Oriented Programming, when using attributes, right? So you’ve got a controller, you’ve got an action, and you tell ASP dotnet that, hey, this is a post? Well, I’ve got to do that by throwing on the post attribute. It’s not exactly Aspect Oriented. But it’s kind of almost there anyway, and like you say, you’re getting experienced with these patterns without realising it when you’re doing dotnet development anyway.

Carl-Hugo

Yes, true. Well, the promise of interoperability that came with dotnet, framework one, it’s finally here. So there’s there’s one thing, the naming is kind of hard to follow when when you’re not following dotnet world. Up close, this will get easier now with dotnet 567. But the dotnet core era with dotnet standard that will also disappear, and all of that it can be very blurry. And up to the new thing, like you said that next dotnet six, but there’s a lot of cool features coming in then. One of them is the minimal API’s. Don’t know if you look at that, like in dotnet, five day they introduced the top level statement. So no more need to create the programme class, you can just go right straight into the programme CS file with minimal API’s, you’ll be able to do that with API’s and everything will be super simple. So this is this will be great for academic purposes and 11 to create real programme, like I said, some people argue a bet against that. That MVC is more structured for for real programme and so on. I love MVC. Don’t get me wrong, but I think that both will have good, great advantages. Because sometime well, as we said, like not not long ago, simplicity is often golden, right? So these will bring simplicity, you said micro service, like you want to build a micro service, you don’t necessarily want like a big MVC structure, and all of that, anyway, can’t wait to try all those new things in the dotnet six.

Jamie

I love the idea that it’s sort of stripping away that ceremony, you can put the ceremony back in if you want, you can create a programme.cs and create a startup class and wire everything back in. But if you literally just want to, maybe you’re just creating an HTTP endpoint to test your UI, right? Well guess what you can single file, there it is. There’s my HTTP endpoint. And guess what it works and it’s returning a marked value. My UI works brilliant. I could just pass that down the line now for an actual proper test, or Thank you saying let’s say I want to create a micro service, as micro service as one controller and he has one route and One thing that he does very well, I guess, well, that’s the SRP, right there, right single responsibility right there doesn’t have to worry about how it’s wired together. You can, like I say, you could put that that ceremony back in, you can regenerate the files around it. But if you do a file new MVC, or a dotnet, new MVC, you know, the majority of the files in programmes, yes. And the majority of startups Yes, will likely be the same, right? No matter how many times you generate a new project and create new controllers and stuff. So I think I genuinely think is a great idea.

Carl-Hugo

Well, oh, yeah, I can’t wait to to really leverage that. And as you were talking about tests, the compiler shall generate that programme file that programme class. So you can test that like, you can do integration testing on your, on your minimal API’s, using like the web, web application factory, and the test server and all of that, that jazz. That’s even better. Because when I tested that the last time that was not in the previews, but this, this is GM, I think, an RC one.

Jamie

And I guess it makes it easier for folks who are new to dotnet as well, right? If you’re a brand new developer, you’ve never written any, any code in your life. And the thing you’re learning is ASP, dotnet core, or whatever they’re gonna call it from version four, version six onwards, if you’re learning that, you no longer have to learn the entire technology stack and how, as always, together, you can just focus on Okay, so if I write this controller class, and I create an, an action method that has my HTTP endpoint, rather, you can then go away and learn how it’s all wired together. But you’re not having to learn the whole stack just to learn how an HTTP handler works, right?

Carl-Hugo

Yes, exactly. And, yeah, you create your own points, and that’s up. But the same, like, that’s what I really love about those top seven statements. And at first, I was not that, in agreement with that, when I saw the spec at beginning, it was like, where are we heading to? And, well, now I changed my mind on that one. But for example, I’m writing a blog series about how to start coding, like, it’s super like the zero level entry level that you want to start coding, like, the first article is, what is a programme, for example. So I leverage top level statement all the way. So you don’t have to do anything like you using system, Console. WriteLine, you write to the console, that’s, you don’t have to create class or anything. So I am able to organise my series by topics like if and conditionals and, and reading from the console and writing from the console without going into object oriented, because we’re playing Lego here, right? So if you know how f work, you can put that f into a method. But the cool thing is, I don’t have to explain to you what the classes what a method is, I can just show you the F. Yeah. So that that’s really cool. And with the ASP. NET API is now that will be the same but for ASP. net. So once you know C sharp a bit, you can learn web development, without knowing everything else, and start building value to either yourself or your company or whatnot.

Jamie

Absolutely. And there is actually I’d never really thought about it. Because when I started learning programming, way, way, way back in the day, I just breeze past Oh, I’ve got a copy of this go analogies, just one line. But I’m copying at 1213 lines of code. And I’m only focusing on this one line. But there’s a section in a book that I read recently called the programme is brain by felina. Herman’s apologies, Dr. hemans, if I pronounced your name wrong. And in in the book felina says that, if you’re looking at 1314 lines of code, and you’re a brand new beginner, hey, supposed to take that in, I supposed to learn all of that. And then, like you realise that nothing about him is even relevant to what you’re learning namespace not required. Class Name not required. I don’t need to know what a class is to be able to write to the console. I don’t really even need to know what a method name is to write to the console. So let’s just get rid of all of that to make it easier for someone to start. And then even then, once you have started, take it all the way For now, because you need to literally not needed. If a class doesn’t exist, the compiler will grab one for you, if a method doesn’t exist, and their method will be created for you, right? You could put all of that back in. But if you want to, you can take it all over again, it’s I think it’s wonderful.

Carl-Hugo

Exactly, you can folk focus, writing the code that you need to write and less plumping, which is awesome. And all the rest, as you said, All the rest is still there. So if you need that full MVC framework, well, you just add MVC, and start creating controllers. And why not mix both or whatnot. And that’s the cool thing, like you pick the tool that you need, or the tools that you need. And boom, you’re good to go. But if you need simplicity, we have it now.

Jamie

And like you say, it’s all about focusing on the code that you need to write. If you have to go File New class.cs, you got to add a whole bunch of using statements, you got to add a namespace, you gotta add a class name, you got to add a method name. And then you get to the point where you’re being useful, because everything else doesn’t matter. The rest of the stuff doesn’t immediately solve the problem. So I’m all for it. I can understand why folks might be against it, but I’m all for it.

Carl-Hugo

Oh, yeah, definitely. And yeah, you said using, I don’t remember if that made the cut for C sharp them, or if it would be in C sharp 11. But there’s also the global using, that you can global use a namespace and never care about it ever again, in all your other files. That is something awesome, too. It’s like, okay, like using system. Like, you almost always have a using system directive and the top of every single file. This is really rare that you don’t use something from the system namespace, and stuff like that. And you can put as global that will be really, really interesting to do to, to play with, I believe.

Jamie

Imagine writing some async C sharp code, without having to include system dot threading dot task everywhere, you know? Yeah, exactly. And yeah, okay. So the tooling can do that for you, too, by just doing Ctrl, Command dot and importing it. But why should it have to? Yes, exactly. Less is more. Yeah, then you can focus on the important bit, which is, like I said it like three times now. But you are focusing on writing the code that solving the problem,

Carl-Hugo

while you’re writing value. I mean, that’s what we’re doing, right? We’re creating value, whether for our own pleasure, or for our company, that they make money, or whatever they make our customers do to be happy with our application. Whatever the reason, we’re trying to create value, and writing less code to create more value is, well, that’s good for everybody. But those were paid by the line of code, but I don’t know that many of them.

Jamie

It’s also less code to maintain as well, right? Yeah, I have to maintain all of those using statements. Let’s say you have a custom namespace, and it moves, well, then you got to go through all that. Again, the tooling will help you with it. But let’s say you’re not using the tool ignorant, let’s say you’re using Notepad or something. Because like when I learned when I learned dotnet, at university, the way we were taught was, you use notepad and the csc.xe compiler. So if you’re going down that route, and some people do, you know, there’s nothing wrong with using vim or Emacs or VS code, to build your code without using any kind of plugins. If you want to go down that route, then it makes it easier for you to have to, you know, you don’t want to make a typo, fix, make a typo, fix somewhere, and then run dotnet build again. And then you get 5000 errors, simply because you change the name of the namespace, but you haven’t changed it everywhere else. So why not let the compiler do it all for you and, and what but the best thing about it is, you don’t have to do it, right. Like with any of the C sharp language additions, you don’t have to do pattern matching. You don’t have to do any of these top level using statements you don’t have to do with async enumerable You don’t have to do any of these things. They’re there for you to use if you want to.

Carl-Hugo

Yes, exactly. Like, are there there’s so many things and like dotnet is like a huge toolbox was like a garage filled with tools and you just pick the tools that you want or need. And yeah, as you If you don’t want to, you don’t need to just leave them there and use whatever you are more comfortable with, or whatever you think is better for your project. Because there’s also that like, this is the important part when you build when you’re building something. This is the context. Like, you cannot say, this is good for everything. But maybe there’s something good for everything. But most of the time, that is not true. So you look at your project, okay, this is the project, this is the scope, this is what we want to achieve, then you build that using the right tools, and then try to be to be to optimise the time it takes to develop it with the quality and everything and you put it together and then you’re happy like the faster gets released? Well, the more happy everybody is, right?

Jamie

Yeah, totally. All of that being said, then, Gang of Four has what I want to say 30, around 2030 different design patterns. Lots of other design patterns have been discovered, and named since Gang of Four came out. But I guess, and this may sound like a really strange question. But do you have any favourite design patterns like ones where you’re like, Oh, I really, really like that I’m being able to solve this problem with, say, strategy or builder or a factory or something. Is there anything that you think, Wow, I’m glad that I get to practice this pattern today? Or is it just a case of? I don’t have favourites? Because all of them are just as good as each other?

Carl-Hugo

Well, obviously depends. Like, it always depends. You said strategy? Well, I am a big fan of dependency injections or strategies clearly want one very useful pattern. But it’s also super simple. So you don’t have to like practice strategy, I guess. Like once you get it spread is simple to to use. So this would be code or small scale, and the bigger scale of things, I’d say Evan driven architecture. So all the messaging like a synchronous messaging, like Kefka. Okay, Kafka is not the pattern, but is the driver. And it’s a of the of the architecture, you can use asier stuff or whatnot. But let’s say Evan driven architecture is something that I really like, because it’s not good for every scenarios. But when you can use that it helps break tight coupling between systems. So you move the coupling from one app, depending on the other to one app, depending on the data contract, and another app, depending on the same data contract, which is really awesome. So brings opens up a lot of possibilities. So in the high, high, higher level, kind of pattern, I’d say. Yeah, event driven architecture, is something I really love. And in the myth between the strategy and heaven evon driven architecture, I’d say Vertical Slice Architecture that I talked in the book, too, when I talk about about event driven, but it’s more theoretical, that vertical slice architecture, because I love not to search everywhere for all the files, or all the whatever are needed for my feature. And I love the idea of bringing all the feature together and building features. Instead of building a bunch of small bits divided into multiple layers. That makes the our life way easier. So that would be a think, am I in my tree pattern. So I have a small one, and nap centric one and a system centric one.

Jamie

I like that because I feel like the vertical slice architecture fits really well with something that in pragmatic programmer where they they use the phrase tracer bullets. I prefer vertical slice architecture to tracer bullets, because traceable it sounds like it’s a bit more violent. But they’re essentially saying build one feature of your app, a controller or maybe even just a single handler and start there and go all the way down to the data source, or to the Event Queue or whatever to the end goal, and come all the way back up. So instead of building a let’s say you’re building an API for a bookstore, right, instead of building the entire system all at once you build I need a controller called books which allows me to get ebook. So I have an action method that gets a book, the action method requires calling, maybe it calls a mediator or maybe it talks directly to the service, it doesn’t, immediately doesn’t matter. So then I need a book service. All I need for the book service is return a book. And then the book service maybe requires a database. So it needs need some way of contacting the database to get a book. So I’ve gotten a book now return that to the service. Now that I have it back in the service, maybe I need a DTO died, some. So details of that book, build the DTO, pass that back to the get a book, action method, boom, you’ve just built a full feature from start to finish using that vertical slice architecture using that Teresa bullets idea, rather than building the entire API, or once you have some immediate value rather,

Carl-Hugo

yes, well, I didn’t add to that, like what you described me as a pretty complicated feature. Like you created the controller service and the repository, and the database and a DTO. All of that, to get the book, what I love, as I said, simplicity, as instead of that, you just get the book, I’d suggest to create the DTO, because it becomes your data contract, which is the same as with Evan driven architecture, like, you know that this won’t change. And when, when it does, while you better tell your clients or your consumers, because while they won’t be happy otherwise. So you have that data contract, then you create the handler that, go fetch that book, and you have a feature. If at some point you’re you need to reuse or there’s some shared logic, then you start with all of these independent feature, and you extract a service or repository or whatnot, and then reuse that logic. So this is really also how I like it. Because what you describe is really good. Like, it’s super classic example. And what I love is when you start explaining a get the book in this way, and you get into so many hoops, you can then stop and look and say, Well, maybe my system is way too complicated. And Pat that back into a small method or whatever you’re using.

Jamie

Yeah, sure that makes sense. Because that fits with with the KISS principle, isn’t it? Yes. And it fits with, let’s say you build a small micro service, and you throw it up onto as your or AWS or GCP, or wherever you’re going to host them. You want that micro service to do as little as possible, because he should only have a single responsibility. But if you’re going to hit that micro service a million times a second, you want the the memory footprint to be as small as possible. So maybe having a service is a bad idea. Maybe you just go here is your data repository, here are your tables, just convert the the row that matches to the DTO and send it back to me. Maybe that’s what you want.

Carl-Hugo

Yeah, well, they Yeah, every system is definitely different. And that’s that’s the part that is really important. And what I feel, is often that when you start building those services and repository, often you kind of get lost, because you try to foresee the future and foresee what you’ll need. And you end up like coding a lot of stuff that either will will be bad for you in the long term or not needed, or you spend a lot of time trying to design that thing, like the best as possible. So you’ll be able to use it later, instead of just going to feature. And I’m not saying don’t use service and report stories, not what I’m saying just so the listener or not the thinking that’s what I’m saying. I mean, everything as a as a purpose. Just sometimes you don’t need that whole structure, you can go simple and just build. But that requires often a bit more, more refactoring skills. So when happened that when I arrived a time where you’re like, Okay, I do have shared business logic, and you need to move that up. That’s where your refactoring skills and your knowledge of design patterns will come into play and, and will allow you to do that extraction and say, Okay, I need a service. Then you create your service class, and you’re able to refactor all of those small pieces and to the cheddar out.

Jamie

Totally, yeah. Most developers aren’t paid to come up with the fanciest, clever solution, we are just paid to solve the problem, right? And if you want to solve the problem with lots and lots of architecture and, and a very complicated way to solve the problem, then totally do that. Or if you want to solve the problem by injecting the repository straight into your controller, and just saying, right, convert this row into this data object and send it back, then also that is a way to solve the problem, right?

Carl-Hugo

Yeah, it’s all dependent on what you’re building. Of course, like, if you’re building an API, we talked API, as I also said, like the data contract, that’s the part that you want to be unique. No matter how you do add, it’s the C sharp cause it gets returned to Jason. And so whatever how you can do that, I don’t know you’re creating your open API schema somewhere? Well, that’s the important part, how you reach that goal, which is the contract. So any consumer will expect this data, how you provide that data really depends on each use case. So as you said, if you want to inject your repository, and by repository, like if you’re using Entity Framework core, for example, well, it is a unit of work with repositories in app. So you inject your DB context. So add in your return the right data, like the data that follows the contract, well, can be fine. Of course, if you’re building a $10 million software, maybe you’ll want you to do something else, but maybe they’ll will still be fine. That’s the key like, and often where the questions are, like, Is it okay or not, is the business logic. Like, if you’re doing like a facade over a database, you don’t really care. I mean, there’s no business logic. So you don’t want three or four or whatever, many layers to update every time somebody in the business wants to add a field, right. But if it’s something I don’t know, a customer facing, or customer centric app with a lot of business logic, them, you have to be more careful of how you build that. Because that logic, you don’t want to duplicate that domain logic everywhere. So that’s where all of those patterns come into play and say, Okay, let’s be something solid together. So every time we make a change, we don’t break everything.

Jamie

And that I think, is absolutely solid advice, if you’ll pardon the pun. But what I’d like to know before we, before we saw it, go back to talking about the book and do a bit of a wrap up. I’d like to know, are there any design patterns or any ways of doing architecture, designing any architecture that you looked at? and went, Oh, that is so clever, or that’s really smart. And I feel like perhaps, from what you’ve said earlier on, maybe event driven architecture, but I’d be very, very interested to find out what it is. Is there anything that you looked at? And went? Well, that’s really smart, in like a, like a design or, or an architecting way of working?

Well,

Carl-Hugo

it’s very hard to say, I think the smart part is more about how people use those patterns. Like patterns are often simple. I don’t think people like sat at a table saying, Okay, let’s create a pattern. It’s more, okay, we’re doing this over and over again. And that works. So let’s, let’s put a label on it. And it’s a name. I don’t want to take anything back from anybody. Like there’s a lot of clever people that name patterns. Like, it’s it’s really not that but I think it’s how people do leverage those patterns. That that artists, the more clever part, though, of all of it.

Jamie

I mean, that’s that’s that is indeed as as good of an answer as I would have been able to come up with. Let’s Let’s because we’ve talked about a lot of stuff today. Let’s remind the listeners of the book title and where they can find it. Right. It

Carl-Hugo

is an atypical ASP. NET Core fire of design pattern guide.

Jamie

So I know that’s available on Amazon and other booksellers. I’ve been told that there is perhaps a second edition on the way is that something that’s there’s coming along, and is that targeting dotnet six perhaps or is it just, hey, there’s some there’s some extra things I thought of that I can throw in?

Carl-Hugo

Yes, it is true. You have good sources. We are working in a second edition and yes, it is targeting dotnet, six and C sharp, then it will be an increment over this one. So we’ll obviously keep most of the content, where updates, like I want to add, for example, the relevant C sharp done and dotnet, six features that would fit in there. I’d like to to update code samples, you know, to dark out net six. We talked about the top level statement and ASP net, minimal API’s, I’d really like to put some of that or some more of that I use top level statement a bit in the current version, I’d like to leverage data more if I have the time to, to revise well as much code sample as I want. Because obviously, like, this is not my main job. I can’t spend all my time there. And that sex is pretty close. So this is still something that I’d really like to put in place like the minimal API that I love that stuff. And we run many surveys, and most readers wanted to see more, learn more about layering and micro services. So I plan on revising those chapters and see what I can do to to, to add more value. Like I think there are still valuable chapters with old try. Well, I’ll explore the possibilities there. See how I can more on those subjects. Obviously, we’re still super early now. So when you will listen to this episode, it’ll be way closer to the release date. But the day of the recording, it’s pretty early in the in the in the lifecycle of that second edition. But these are the big line that I say, I want to tackle.

Jamie

That’s one of the things that would that would make me reserved about, about writing a book, especially one that’s on a programming topic, because like, especially dotnet now is gonna have a yearly release rate. And so by the time that you finish writing a book, hey, the new version of this stuff is, is out. So you got to update it. And then once you’re finished today, the new version of the stuff is out. Yeah. So that’s, that’s what would stop me from doing it.

Carl-Hugo

Yeah, it is true. Right now the .NET release, cadence is .NET 6 is an LTS - so a long term support version - than seven will be not an LTS than eight. So there’s also that that will help. And also, we’ll also think about some other ways to maybe bring content; I’ll just hand like this, but nothing thing yet sure, or anything. So I don’t want to go into details with the, we started to think about ways to bring more content without like changing the whole book. Because the book is, it is technology centric, like we’re targeting a certain version of .NET. But the more .NET will evolve, I think, the less the version will matter. Because the patterns don’t change with .NET. There’s just some code samples that will change, now with the new minimal API as well, there’s that was not inexistent before.

The top level statement, when I started writing the book. This is a fun story. It was theoretically targeting .NET Core 2. It was supposed to be “Hands on Design Patterns with ASP. NET Core Two,”

Jamie

Right.

Carl-Hugo

And I thought I’d be writing that like lightning fast. And I was like, okay, and I’ll skip the details. But we have more than double the page count that was planned initially. And it takes a lot of time to write a book. I’ve learned that. So yes, the more it goes, the more of those features that will kind of stop happening; like the top level statement, that’s a big change but then .NET eight or well, seven or eight or nine, chances are there won’t be more like huge changes like that.

So yeah, the content is still relevant, no matter the technology, the version of the technology, but I will have more, less maintenance to do on the code base. I think that the more it goes, Well, hopefully.

Jamie

Yeah, well, less maintenance is always the goal, right?

Carl-Hugo

I like sharing knowledge. And that’s why I have a blog for since forever. Mind you, well, I stopped at some point, but I started back few years ago. That’s why I wrote the book: to share knowledge and experience. So it’s just the time like, I have so many ideas and projects in mind that at some point, it’s just I don’t have more than 24 hours a day to, like, do all of that stuff.

Jamie

So how can the listeners find out more about you? And you mentioned that you have a blog? So you know, and I think I spotted a few references to some NuGet packages that you’ve authored throughout the, there were references in the book, to a few NuGet packages and stuff like that. So where can folks find out more about all that stuff?

Carl-Hugo

Well, there’s my blog, for sure. There’s the NuGet packages, I have a lot of packages or open source projects that I published on NuGet that kind of evolved during the years. So those open source projects, they started, like something I needed, I coded it in the open and I deployed them. There’s some that I maintain more than others. People can do whatever they want with them. I believe most of them are MIT licence. So it’s like take it or don’t.

And besides that, there’s Twitter. I’m not social media expert. I don’t tend to share my life on social media, either public or private. I don’t know, that’s me. But I do my best to to post stuff on Twitter, like either a good article that I found or retweet interesting topics about .NET. For example, right before recording the show, I retweeted something from David Fowler from Microsoft. Always posts great stuff. So I retweeted something about the new API’s from .NET 6. And when I do blog post, I obviously post that on Twitter as well. So I use that as advertisement. But yeah, I do advertise there. So if you want to know more about my blog, and all of that, you’ll see me tweet about the article I post. Yeah, follow me on Twitter, that’s probably the best.

Jamie

I’ll make sure to put a bunch of links to all of the stuff you just mentioned, the Twitter, the blog, the open source, NuGet packages, stuff like that - they’ll be in the show notes. So make sure you you know, you click through to read those because otherwise, you won’t be able to find these these links and stuff.

Carl-Hugo

Yes. Don’t be shy to reach out like feel free, like send me it or a tweet or whatever a PM on Twitter and like, usually, like I may not answer like in a second. I think real time communication is overrated. And people are getting addicted to it. But I do, like reply to people. So feel free to reach out as well.

Jamie

Well I guess all that really remains to say Carl-Hugo, is thank you ever so much for being on the show. Again, I have definitely learned a whole bunch of stuff about what’s coming in .NET and being able to reinforce the knowledge that I’ve picked up from reading your book. So I really appreciate that. And I really appreciate the time that you’ve taken out of your evening to talk to us all about this. So thank you ever so much.

Carl-Hugo

Thank you very much for having me. It is an awesome show. I had a lot of fun speaking about .NET with you. It was amazing. So anytime feel free to invite me back and let’s talk about something else and .NET or whatnot.

Jamie

Most definitely Carl-Hugo, most definitely. Yes, you can expect another invite from me. Absolutely. So thank you so much.

Carl-Hugo

Thank you

The above is a machine transcription, as such there may be subtle errors. If you would like to help to fix this transcription, please see this GitHub repository

Wrapping Up

That was my interview with Carl-Hugo Marcotte about design patterns, a little on .NET 6, and his book An Atypical ASP .NET Core 5 Design Patterns Guide. Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at dotnetcore.show, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice - head over to dotnetcore.show/subscribe for ways to do that - reach out via out contact page, and to come back next time for more .NET goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places