Latest / DevQuestions with Tim Corey / 057 What Are the Common Application Layers? Is 3 Layers Standard?
Transcript
- 0:00SPEAKER_00: Welcome to the Dev Questions Podcast with Tim Corey.
- 0:03SPEAKER_00: Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology.
- 0:12SPEAKER_00: If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered.
- 0:19SPEAKER_00: Now, here's your host, expert developer and online educator, Tim Corey.
- 0:25SPEAKER_01: What are the common application layers?
- 0:28SPEAKER_01: Is a three-layer application or a three-tier application the standard way of going?
- 0:34SPEAKER_01: This is a question that Samir asked, and he's asking about kind of the best practices here.
- 0:40SPEAKER_01: Is it always to have certain layers then have other optional layers?
- 0:44SPEAKER_01: How does it all work and is it always the same?
- 0:47SPEAKER_01: And so this is a great question to talk about on dev questions because there's a lot to talk about and a lot to think about when talking about application layering.
- 0:58SPEAKER_01: So the the answer you probably are going to see coming from a mile away, the one that really could be the answer to just about every dev question video is really applies here too.
- 1:11SPEAKER_01: Is it depends.
- 1:13SPEAKER_01: And that's something that as a newer developer that may be frustrating.
- 1:18SPEAKER_01: It feels like you know, that's just a kind of a cop-out.
- 1:22SPEAKER_01: And the reality is as you progress in your development, you realize that every application is different.
- 1:31SPEAKER_01: And if you try to apply the same things the same way to multiple applications, you're gonna cause friction, you're gonna cause problems because not every application fits the same mold.
- 1:47SPEAKER_01: So if you don't take an it depends approach, then you're gonna try to shoehorn things in that just don't fit.
- 1:55SPEAKER_01: So let's talk back 20 plus years ago.
- 1:59SPEAKER_01: When I first started in development, um, of course, I didn't write great applications.
- 2:04SPEAKER_01: Um, I wasn't born writing code.
- 2:06SPEAKER_01: Um, I learned on the job and I learned some pretty bad techniques.
- 2:11SPEAKER_01: But even the techniques I saw better developers doing, a lot of it was kind of mashed together.
- 2:20SPEAKER_01: Now, the textbooks, when you went to a class or when you saw a presentation on good design, they were spouting the idea of a three-tier architecture.
- 2:32SPEAKER_01: And it was very, very clear.
- 2:34SPEAKER_01: It was the user interface layer, there was the business logic layer, and then there was the data access layer.
- 2:40SPEAKER_01: And those were uh defined as layers on a cake, where the the top layer only touches the layer below it, and that layer only touches the layer below it and the layer above it.
- 2:51SPEAKER_01: So that was how applications were described.
- 2:56SPEAKER_01: We build these three-tier applications.
- 2:58SPEAKER_01: If your application is going to be a good application, then it's gonna be a three-tier application.
- 3:05SPEAKER_01: That's not what we wrote.
- 3:07SPEAKER_01: I mean, you know, if you had Windows Forms back in the VB6 days, um, you know, you drag and drop your buttons on, you double-click the button, and that button, let's say it loads data.
- 3:17SPEAKER_01: Well, that talked to the database.
- 3:19SPEAKER_01: And yet it's on the user interface right behind the button, code behind for the event.
- 3:25SPEAKER_01: It was ugly.
- 3:26SPEAKER_01: Um, and really, we wrote a lot of one-tier applications, applications that were just poorly coded.
- 3:32SPEAKER_01: Um, but some of them weren't.
- 3:36SPEAKER_01: Even though they're a one-tier application, some of them fit the job they were doing, and that was okay.
- 3:42SPEAKER_01: And this is the the kind of the starting point for moving away from that very, very clean-cut three-tier application.
- 3:52SPEAKER_01: The starting point is realizing that, you know what, for some applications, I just need one tier.
- 4:00SPEAKER_01: I just need a user interface that does everything.
- 4:04SPEAKER_01: Because all I need to do is maybe load a little data from a database, allow the user to modify it and save it back.
- 4:11SPEAKER_01: That's simple.
- 4:12SPEAKER_01: It's probably not something you'll reuse in another context.
- 4:16SPEAKER_01: It's probably not something you create a whole lot of architecture around.
- 4:20SPEAKER_01: We could make that modern and you know, create dependency injection, create multiple class libraries and all this disconnected stuff, and you'd have 30 projects in Visual Studio open in order to do that one task.
- 4:36SPEAKER_01: And while it feels like we're being better, we're we're we've got all this stuff in place, but the reality is it's now a whole lot more complicated to do the same job, and that's where we we start to have to evaluate and go, oh, we don't need all that complexity for this specific instance.
- 4:57SPEAKER_01: That's why it depends, is so important.
- 5:00SPEAKER_01: Now, after three-tier, we went to N tier.
- 5:06SPEAKER_01: The idea of N tier being there can be lots of tiers and lots of different options.
- 5:10SPEAKER_01: This is where the complexity comes in of, hey, we we need a totally separate layer for logging, and we need a separate layer for this and for that, and you know, some layers go to the side and they touch all the layers, and some layers just touch one layer, and it got kind of messy.
- 5:26SPEAKER_01: But the reality was that even in the textbook three-tier application, it was still messy.
- 5:35SPEAKER_01: It was still complicated because usually that user interface did still talk to the database directly, it still knew about it, and really the business logic kind of flowed up into the user interface because you need some logic in there to um display things a certain way or you know apply certain filters based upon the business rules.
- 6:00SPEAKER_01: And it kind of morphed down in the database as well because you didn't want to put data in a database unless it passed certain checks, which were business logic, but they were really at the database layer.
- 6:13SPEAKER_01: And before you knew it, you had kind of this really gray area.
- 6:17SPEAKER_01: And the textbooks made it look so pretty and perfect, and the real world was messy, and that's really how development works.
- 6:27SPEAKER_01: If you try and make it real pretty and real perfect and all the rest, the real world's gonna hit you pretty hard because the real world is messy, the real world takes compromise, and that's why we don't just apply every best practice to every project.
- 6:46SPEAKER_01: That's why every design pattern doesn't get applied to every project, not even all the solid principles, which are principles higher level, they don't get applied to every project.
- 6:57SPEAKER_01: It really is a little bit more pragmatic than that.
- 7:01SPEAKER_01: Yes, there are certain things you want to do, but for the most part, we need to approach a project based upon what's best for that project, what's best for that team, what's best for that language, what's best for the future of that project.
- 7:21SPEAKER_01: So when it comes to layers, first of all, layers aren't nearly as clean cut as you would think they are.
- 7:31SPEAKER_01: All right.
- 7:32SPEAKER_01: I have rarely seen an application where the layers actually worked the way that they were supposed to.
- 7:40SPEAKER_01: Yes, you can see some applications where everything's really, you know, um separated and segmented, and they've got, like I said, 18, 20, 30 projects to get something done, but even so, there's some messiness in there, some cross-cutting concerns, some things that touch more than one layer.
- 8:00SPEAKER_01: And sometimes you have to ask the question did that extra layer or did that extra complexity give me extra benefit?
- 8:10SPEAKER_01: And where is that benefit?
- 8:13SPEAKER_01: I would recommend that you really look at an application when you're building it and look at how can I make this as simple as possible, both now and for in the future.
- 8:29SPEAKER_01: And that's where you'll apply some of the complexities.
- 8:32SPEAKER_01: Uh dependency injection is a great illustration of that.
- 8:36SPEAKER_01: That's a complexity.
- 8:38SPEAKER_01: Creating that dependency injection, putting all your dependencies in one spot, creating a system where you ask for dependencies and make sure you get the right type, whether it's a a transient, one that's a new instance every time, or a singleton, that's one instance for the lifetime of your application, knowing when to get what and how to get that, and you know, putting data into them, and that can get quite complex.
- 9:03SPEAKER_01: And for some applications, that's too much.
- 9:06SPEAKER_01: But when it comes to allowing you to easily manage that in the future, usually depends the injection pays off.
- 9:17SPEAKER_01: But not always.
- 9:19SPEAKER_01: So evaluate that, evaluate your complexities up front.
- 9:24SPEAKER_01: When you start sitting down to a project, don't think, oh, I want this design pattern, this design pattern, this design pattern.
- 9:30SPEAKER_01: Start with what does the application do?
- 9:35SPEAKER_01: How can I make this as simple as possible to build, as simple as possible to maintain?
- 9:44SPEAKER_01: And out of that will naturally come some layering.
- 9:50SPEAKER_01: There'll be some things like, well, we should probably create a class library for this to get away from the UI.
- 9:57SPEAKER_01: Why?
- 9:58SPEAKER_01: Why do I create a class library?
- 10:00SPEAKER_01: In my projects, usually traditionally on YouTube, I'll create a UI layer and then a class library.
- 10:07SPEAKER_01: I call a layer.
- 10:09SPEAKER_01: Um, they can kind of be the same thing, even though they are in two different projects.
- 10:13SPEAKER_01: That can still be one layer, but I create two separate projects, usually, a class library and the UI.
- 10:21SPEAKER_01: And the reason I do that is because that's usually where our demos land as far as complexity.
- 10:29SPEAKER_01: They land in the idea where I might want to replace the UI at some point, or I want to be at least separated enough from it so that I can add a new UI or I can change something out.
- 10:41SPEAKER_01: The Timco Retail Manager is a little bit more complex example of that, where we create an API.
- 10:47SPEAKER_01: And then we have a WPF project that is talking to a class library that's talking to the API.
- 10:56SPEAKER_01: But then we create a Blazor project that talks to the same class library that talks to the same API.
- 11:03SPEAKER_01: So we've we've got some complexity there, but we've also made it less complex when it comes to building out two different user interfaces that both talk down to down through the API layer and so on.
- 11:18SPEAKER_01: So there's a balance there in how you do things.
- 11:22SPEAKER_01: But don't just say, okay, new project, gonna create a class library, gonna create a user interface.
- 11:30SPEAKER_01: You need to know why you're doing those things.
- 11:32SPEAKER_01: Don't just do it because Tim did it.
- 11:34SPEAKER_01: Don't just do it because it's the right thing to do.
- 11:38SPEAKER_01: Do it because it makes sense for your application.
- 11:41SPEAKER_01: That means you need to know up front what your application is going to do.
- 11:46SPEAKER_01: You need to know how to design your application before you build.
- 11:50SPEAKER_01: So design your actual application, not the not the structure as far as number of layers, etc.
- 11:57SPEAKER_01: Design what your application is going to do, and then based upon that, build out your your structure as far as number of layers, how you're gonna set it up.
- 12:10SPEAKER_01: Is it gonna be onion architecture, three-tier, n-tier, uh domain-driven design?
- 12:16SPEAKER_01: It's gonna be microservices, what's it gonna be?
- 12:21SPEAKER_01: That's up to you based upon what your application is being built for.
- 12:26SPEAKER_01: So the answer to are standard layers, not really.
- 12:34SPEAKER_01: Um I guess the only standard layer I can think of is probably the user interface level layer.
- 12:40SPEAKER_01: That's there's always a user interface.
- 12:42SPEAKER_01: Even in things like services, where you don't use the interface, there's still a user interface.
- 12:49SPEAKER_01: It's just that it's the computer's using it, you know, an API.
- 12:54SPEAKER_01: The API itself, the the endpoints.
- 12:56SPEAKER_01: That's a user interface.
- 12:58SPEAKER_01: Even though it's not a graphical user interface, it's still a user interface.
- 13:02SPEAKER_01: So there's always a UI layer of some type, something that's usually an executable.
- 13:08SPEAKER_01: If it's desktop-based, uh console app, service, uh, wind form WPF, UWP, it's an EXE.
- 13:17SPEAKER_01: Or it's a the the web project that's installed, an API, the uh MVC, Razor Pages, Blazor, and so on.
- 13:27SPEAKER_01: Those are user interface projects.
- 13:30SPEAKER_01: And every application is gonna have one of those of some type.
- 13:34SPEAKER_01: Otherwise, it won't run.
- 13:36SPEAKER_01: So that's the only real given as far as traditional layers go.
- 13:44SPEAKER_01: Beyond that, you may or may not even have data access.
- 13:48SPEAKER_01: Maybe there's no need for data access.
- 13:50SPEAKER_01: I've created applications like that where there's no database involved at all.
- 13:55SPEAKER_01: So there's no need for that layer.
- 14:00SPEAKER_01: And there may come a time where you say, hey, I want to add these five layers because this is what's necessary for this application.
- 14:07SPEAKER_01: The key is keep it simple, keep it easily maintainable.
- 14:13SPEAKER_01: The more you learn about other systems, ways of doing things, ways of laying things out, they can add more tools to your toolbox of options to go down towards based upon what your application needs.
- 14:27SPEAKER_01: If your application needs those complexities, then you've got that opportunity to add those or do those things based upon your knowledge.
- 14:35SPEAKER_01: The more you know about different ways of doing things, the more options you have.
- 14:40SPEAKER_01: But always start with the answer.
- 14:43SPEAKER_01: It depends.
- 14:45SPEAKER_01: Okay.
- 14:45SPEAKER_01: That's really gonna help you become a better developer.
- 14:49SPEAKER_01: Let the application dictate the design.
- 14:53SPEAKER_01: Don't have the design dictate the application.
- 14:57SPEAKER_01: Okay.
- 14:58SPEAKER_01: Great question.
- 14:58SPEAKER_01: Thanks for asking that.
- 15:00SPEAKER_01: If you'd like your question answered, let me know.
- 15:04SPEAKER_01: Excuse me.
- 15:05SPEAKER_01: Let me know down in the comments, the YouTube video, or by going to I am Tim Corey and looking for the podcast page.
- 15:14SPEAKER_01: Yes, this is a podcast.
- 15:16SPEAKER_01: If you're watching on YouTube, then you can go find us as a podcast episode instead and just listen to me talk because all I'm doing is talking on camera.
- 15:23SPEAKER_01: So um there's not a whole lot of visuals here.
- 15:26SPEAKER_01: If you don't want to see my face, if you haven't seen my face because you're watching listening to the podcast, hey, I have a YouTube video of this if you want to check that out instead on YouTube.com slash I am Tim Corey.
- 15:39SPEAKER_01: Thanks for listening, and as always, I am Tim Corey.
- 15:42SPEAKER_00: Thank you for joining us for this episode of Dev Questions.
- 15:45SPEAKER_00: Tim is committed to making it easier for you to become a developer.
- 15:49SPEAKER_00: If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions.
- 15:56SPEAKER_00: You can also send your questions to questions at IamTimcorey.com.
- 16:01SPEAKER_00: Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did.
- 16:08SPEAKER_00: When you're ready to learn to think and code like a professional developer, head over to IamtimCorey.com and enroll in a course.