How Do I Structure My Application?

welcome to this episode of Dev questions with Tim Corey join us as we tackle the questions you are asking about a career in software development understanding the industry and new technology if you are just starting out or you want to grow stronger as a developer this is the place to get your questions answered now here's your host expert developer and online educator Tim Corey how do I structure my application what are the best practices for how to create that perfect structure this is a question from a suggestion site and it's one we're going to tackle in today's episode of Dev questions now if you have a question go to suggestions.imcorey.com and ask your suggestion there or ask your question there or look at somebody else's question and upvote it to hopefully see it in a future episode of Dev questions so what's the perfect structure for your application how do you lay things out so that they're designed really well and you've probably know what I'm going to say right now but it depends and yes it depends almost always the right answer may I be the one that explains everything fully but it's the right answer because it does depend it depends a lot on a lot of different things besides just what you asked but let's talk about the ways to structure an application let's start there there's lots of different ways to structure an application if there's one perfect one we'd only have one right so you could have domain driven design or you can have the onion architecture or three layer design or cqrs or everything in the code behind of your forms You Know Who You Are so what's the right way well the right way depends on the size and complexity of your application so a key Point here it's one we have to understand before moving forward and we'll talk about the the five things to work through when it comes to figuring out the right architecture right layout for you but the key point to understand first is that architectural design patterns have a cost the thing they fix needs to be more expensive than the cost of the pattern it's really important to understand that anytime you add in design pattern add in this structure or this layout there's a cost to it and it needs to be less than the cost of not doing it so you have to have this balance because you know there's a there's a really easy way to see this is I have a video on YouTube that is on the the perfect console application and they build outfit and it's yes tongue-in-cheek it's a little bit facetious but we build out this really complex uh console application which by the way is also really good at teaching and things like how to put dependency injection in a console application how to talk to your app settings and other things that you kind of do need for some console applications but in the end of the day we build a hello world application that need all those different files and that depends the injection and structure and all the rest to say hello world well no we just need one line that said console.writeline hello world done okay so we need all that complexity but on the other side I see Enterprise applications that have Windows forms let's say as their user interface and when you open the code behind for Windows forms you see all their their UI logic all their business logic all their data access logic it's all in the code behind that's also not a great design okay so how do you figure out that middle ground how do you figure out when to apply patterns or when to create certain structures or when to break things apart when to separate things in different ways so let's talk through that I think there's really five Keys here the first key is to start simple one user interface one class Library start there and yes I do want to see some that broken apart now okay a very small application might not need a class Library if you create microservice you might not even need that class library but for talking about some type of monolith and monolith is not a bad word monolith is probably the right way to go in most circumstances but start with one UI and one class library and try and keep it just there start there and then as you go through your design process as you go through your building process if you say you know what no we need some more complexity maybe you need a folder structure in here maybe we need some more separation or or grouping of things a certain way only refactor only bring in those patterns when complexity is significant there's a a principle called dry don't repeat yourself and this is one of the most abused principles out there because everyone knows it and so everyone also applies it in the wrong spots too accidentally and one of the ways I see it applied poorly is when you see yourself repeating something once so you have two copies of something and you say ah dry don't repeat yourself and so you create you know a class for that and create a method and that you put in depends the injection and you set us up so you have one place one method call for where you would otherwise have two methods or two bits of logic that's probably an abuse of dry because really for dry you want to say hey you know what I've done this three times I noticed four times I've started to see a significant repetition because a little repetition is okay in fact it's better than bringing the complexity in of trying to refactor that out into a separate method and calling that in a lot of circumstances so that refactoring needs to happen only when complexity is significant number three don't separate related things too often I see people looking to create separation everywhere where I say okay every bit of code has to be a library somewhere it cannot be connected to anything else we're going to have five different libraries the user interface is going to have zero code in it it's all going to go right to a library okay that's a problem because what you're doing is you're separating things that probably go together I've had people ask me they say okay Tim I know that there's a one-way relationship with a library where the library doesn't know what the caller so say the user interface can call the library but the library can't call the user interface that's a problem because my code needs to know about the user interface and the user interface needs to know about my code what you just described is user interface code it needs to be in the user interface not in a separate Library because those two shouldn't be separated because they're really one entity so that separation all it did was add complexity it didn't add value so don't separate things that are related okay put things together that go together number four your goal here is to keep it simple that may sound obvious but really it's not once you get into the heat of battle once you start writing code you start thinking about okay I can implement this design pattern I could Implement that design pattern I have 18 more in my back pocket that I I know about so I know I need to put those in there somewhere that's adding complexity that's not the goal the goal isn't to get design pattern Bingo okay you're not looking for how many of these things can I cram into my application the goal of writing code is to keep it simple I said before but as a junior developer typically you write simple code to solve simple problems as a mid-level developer you write complex code to solve complex issues and as a senior developer you write simple code to solve complex issues that's what you want to achieve you want to achieve the ability to write simple code to solve complex problems create simple applications that solve your goal rather than complex applications because you have to maintain it or more likely the person coming after you has to maintain it and when it's too complicated it's just not worth it causes too many problems and I've had I've paid for applications been completely built and I look at the code and you know what I didn't spend enough time working with the developers and so that's super complex to do a simple job I'm gonna throw it out let's start over because the goal is to write simple code write simple code don't write complex code don't try to bring in design patterns because you've heard about them or you think they'd solve these problems wait until you have a problem that is going to be made better easier less complex if you add that pattern okay when you start adding things and realize they can become more complex that's a problem all right and number five it kind of ties into all the previous let the the situation dictate the structure don't start with a structure too often people say what kind of architecture should I have should it be domain driven design should be cqrs should it be an architecture should it be the three layer stop let the situation Define the structure because today it might be this tomorrow it might be that for a different application if you try to come in with preconceived notions with preconceived layouts then what's going to happen is you're going to introduce a lot of complexity where it's not needed so I know it doesn't give you an exact create these folders create you know put these things here but that's because it comes back to it depends and if you hear someone say no this is the way of doing things always that's a problem that's not good advice because that doesn't take into account your situation or your code or what you're trying to accomplish so you need to figure out based upon what works for you and you know what the same application might be built and structured differently in two different companies because they have two different teams in two different ways that seem simplest to them so that's okay pick what works for you figure out how to make things as simple as possible and move forward from there I hope they answered your question thanks for asking it thanks for listening and as always I am Tim Corey [Music]

Channel: IAmTimCorey

Views: 9,264

Keywords: .net, C#, Visual Studio, code, programming, tutorial, training, how to, tim corey, C# course, C# training, C# tutorial, .net core, vs2022, .net 6

Id: r5G2OiYZAvk

Length: 12min 25sec (745 seconds)

Published: Thu Jul 20 2023