The real world has to be considered when choosing an application architecture.
- [Narrator] The problem with courses and software examples online is that the author comes up with a contrived example to illustrate points and features in ways that are not particularly applicable to the real-world. The saccharine image that this presents is usually understandable, but can break down when applied in practice. While I endeavored to bring in a more substantial example for this course that presents some of those problems, it is still not real-world software and will have some holes in it. There are no real requirements.
I built it by myself. There won't be any long-term maintenance or QA or real users. The software we're using is just not a finished product. So why bother? There isn't really a substitute for real-world experience. Some principles and pieces in this course's examples seem like overkill, but when applied in the real-world, they provide safeguards, or guidelines, that are invaluable. The ideas presented here are not the only way to do it, but they are a good start and should be adapted for your situation as necessary.
Real software has real people working in a team against real requirements. A real team has variable skill sets, different levels of understanding, different mental models at the same piece of software. Real requirements often change, sometimes a lot. We can't control for all of these variables, but we can do several things to mitigate the pains of reality so that we can still come up with a product when the money or time run out. We can't talk about software architecture without spending some time thinking about the whole Software Development Life Cycle.
How and why the application is being built directly affect the design. There isn't a perfect architecture for any non-trivial software, which means that we can always try and do a better job than before. Often, developers think of software as code, but since the code has to exist in the real world, we have to consider the environment when building the software as well. We want to mitigate the problems that the real-world presents with architectures that consider the whole Software Life Cycle, not just the code.
Keep these ideas about real software in mind as we talk about multiple layer architectures. It might seem tedious at first, especially if you have been writing code with multi-layer or multi-tier architectures for a long time. We have to have a foundation to bring architecture entity framework in on top of. With that, let's talk about the reasons and methods behind splitting applications into layers and sharing code across tiers. The next few videos will build a baseline of general software architecture concepts that will lead us to be able to incorporate entity framework, so that it provides the most benefit and the least amount of trouble.
- What is good application architecture?
- Real-world software and the SDLC
- Common knowledge and maintenance
- Choosing an architecture
- Design patterns with EF
- Debugging and error handling
- Architecture for the web with ASP.NET
- Designing for unit testing
- Strategies for dealing with common performance issues