An architect's job is to manage complexity, not increase it. Yet the developer life is filled with jargon, acronyms, and seemingly infinite choices. So how do we know when complexity makes sense? Viewers will learn when abstractions are justified and walk away with an understanding of the merits of various approaches for structuring the business, service, presentation and data access layers with a pragmatic, real-world mind set.
An architect's job is to manage complexity, not increase it. Yet the developer life is filled with jargon, acronyms, and seemingly infinite choices. So how do we know when complexity makes sense? This course discusses when abstractions are justified and outlines the merits of various approaches for structuring applications with a pragmatic, real-world mind set. The discussion begins by outlining philosophies for thinking about architecture and considering the benefits of doing the simplest thing that could possibly work. Then we dive into various design patterns and technologies to consider within the business, service, presentation and data access layers. And in the final capstone module we'll consider two specific architectures and discuss the contexts where each makes sense. You'll learn when table module, active record, DDD, and ORMs are useful and walk away with the tools to better evaluate and justify complexity as an agile software craftsman. Like any responsible architect, we'l focus on the value of keeping things simple whenever we can.
Business Logic Layer Hi, I'm Cory House, and this is Architecting Applications in. NET. In this module we'll talk about the business logic layer. You can catch me on my blog at BitNative. com, or on Twitter @housecor. So our agenda for this module is to start off by discussing layers and tiers, and the benefits, and downsides of these approaches. Then we're going to look at four different ways to structure our business logic; the transaction script, table module, active record pattern, and finally, the domain model, also known as domain driven design. So in. NET, there is a massive list of options for us to consider on each one of the layers. In this module, we're discussing the domain layer that sits there sandwiched in the middle. But throughout the course we're going to have separate modules that discuss each one of these distinct layers. So, on the domain layer, you're ultimately making a decision on which server side language you would like to choose within. NET. Within this course, we're going to discuss different patterns that you can use to structure your business logic. And you'll also notice that I might use different terms for the layers throughout this course. You might hear me say presentation, or UI. Service is the same as the API layer. I might call the domain layer the business logic layer, and the persistence layer could also be called the data access layer, or DAL. These are equivalent terms, so if you hear the one on the left, it's the same as the one on the right.
Data Access Layer Hi. Cory House here again. This is Architecting Applications in. NET. In this module, we'll discuss the data access layer. You can catch me on my blog at BitNative. com, or on Twitter @housecor. In this module, we'll be discussing the data access layer, and its responsibilities, and we'll see very quickly that the decisions that we make within the business layer impacts how we build our data access layer. We'll also look at object relational mapping, and when it makes sense, and what particular problems it solves. We'll look at the repository pattern, which can abstract away our data access. And finally, we'll look at stored procedures, and the benefits, and costs of using them for data access. In this module, we'll be discussing the data access layer. There's a wide variety of approaches for accessing the database in. NET. Options range from simply using raw ADO. NET, or going all the way to the other side and using rich ORMs, like Entity Framework, or NHibernate, and sitting somewhere in between are popular micro-ORMs, like Dapper, ORMLite, or Massive. The data access layer talks to the database. It abstracts away SQL that's run against the database. It handles transactions, and it adapts our object model to a more relational model, assuming that we're using a relational database.
Architectural Levels Hi. I'm Cory House, and in this final capstone module on Architecting Applications in. NET, we'll discuss architectural levels. I think it's easiest to discuss architecture by discussing the extremes, by comparing really simple, to the more complicated enterprise approach. So, for this discussion, we're going to discuss what I call the Level 1 approach. This is the whole idea of the simplest thing that could possibly work. Now given, you could argue there might be something simpler than what I'm going to discuss, but this would be a common simple approach to get an application out the door quickly. In contrast, the Level 3 architecture uses a number of enterprise approaches to build an application that is more complex, but also potentially more scalable. And then, of course, Level 2 sits somewhere in between, and we won't flush this out into detail, but we will talk about a number of different approaches to creating a Level 2 style of application.