Watch videos with subtitles in your language, upload your videos, create your own subtitles! Click here to learn more on "how to Dotsub"

ASP.NET MVC Storefront Part 1: Architectural Discussion and Overview

0 (0 Likes / 0 Dislikes)
  • Embed Video

  • Embed normal player Copy to Clipboard
  • Embed a smaller player Copy to Clipboard
  • Advanced Embedding Options
  • Embed Video With Transcription

  • Embed with transcription beside video Copy to Clipboard
  • Embed with transcription below video Copy to Clipboard
  • Embed transcript

  • Embed transcript in:
    Copy to Clipboard
  • Invite a user to Dotsub
[Microsoft ASP.NET] [www.ASP.net] [ASP.NET MVC Storefront][Part 1][Architecture] Hi, and welcome to part 1 of the MVC Storefront; It's an ongoing series where we're going to build a real-world eCommerce store using ASP.NET MVC. My name's Rob Conery, I work for Microsoft, and my e-mail is [email protected] Be sure to e-mail me if you have any questions about what you see here. You can also leave a comment on this blog. Let's talk about the idea here and what we're trying to do, and that is build out an eCommerce store using ASP.NET MVC. We're primarily looking for your feedback—any thoughts and issues that you might have— they're very, very important to us. We're going to try to webcast the process to as fine-grain detail as we possibly can and show you every decision that we have made. In addition, we're going to focus on Test Driven Development, so if you've never used Test Driven Development before or if you're just curious about it and how to do unit testing in general, this might be very interesting for you. Finally, we're going to try to be agile, which means we're not going to do a big design up front and gather requirements. What we're going to do is take smaller requirements and code out baby steps as we move through this application, taking your feedback. The core architectural pattern we're going to be using is a repository pattern. This involves using lightweight interfaces to pass data between your database and your application code. It's a very testable pattern, and it's going to help us stay focused on TDD as we develop this application. When I started doing this, I thought it might be nice to touch bases with Ayende Rahien. He's really a champion at the repository pattern and well known for his work within Hibernate. He and I did a peer programming session, and I recorded it with his permission. Here now is Ayende. >> If you can simplify everything to an interface—that's a good idea. If you're moving between the layers, you want to have as fast as moving and as simple as possible. In this case, forcing the client to deal with— and in this case the client may be yourself or the controller or something like that— forcing them to deal with something—a custom—is just putting another burden on that, so I like to have an IList, or in my case I go down to ICollection, or even IEnumerable in many cases because I don't really want to have a contact between the services determine additional behaviors. >> So you can imagine this concept with the idea that maybe someone in the cubical next to you wants to share some data with you. Imagine—if you will—that they came over to your cubical with their hard drive in their hand. You would look at them and say, "What are you thinking? I'm not going to use that." And they said, "Oh, it's really easy; all you've got to do is lift the case off your computer, and we'll stick this hard drive in place, and then you'll have the data. I can take care of this in just a second." Well, that's probably a little more difficult than it needs to be. All you really care about is the data that they're trying to share with you, and so what might be a little easier is to use what I always like to use— in this analogy—it's a flash stick. You don't care how it works; all you care about is that it's got a little USB interface on it, and then you can stick that really common interface into your computer and share the data— that's the idea here—is you don't really want to get into the internals of how it works, all you really want is an interface that you can use. I talked to Steve Harman as well, and he underscores this point with some really, really nice remarks. Listen to what he had to say the other day when we were doing a peer programming session. >> There's the whole interface segregation principle, which basically just says, "Keep your interfaces lightweight" because if I'm going to implement your interface, I only want to implement the couple of things I'm really interested in. >> So think of this in terms of a football team. Each player on the front line has a specific role and responsibility that needs to be carried out. As long as it carries out what it's doing, the other players can carry out what they're doing. So if everything is working together properly, and the information they pass back and forth is as simple to receive as possible, all things happen in a good way. So, getting started here, we're about to flip over to Visual Studio, but I had a good talk with Phil Haack before I got things started— he's the Project Manager on ASP.NET MVC, and he's also a proponent of Test Driven Development. One of the issues I was having was a bit of a chicken-and-egg syndrome; in other words, I have a database that I need to use, I have some code I'm ready to write, but what do I do first—do I write a database? Do I need to test the database? Do I write my model, and do I need to test it? How do I get started? The short answer is that if you're a purist, you probably want to start writing tests write away. But if you're not, it's okay still to work on your database or work on your model straight away. So that's what I did: flipped over to Visual Studio, and I started to code. [Visual Studio 2008][Initial Project Setup] Here we are in Visual Studio 2008, and this is the solution we have for the eCommerce application. I have 4 basic projects right now—Web application, Test application, we have a class library for our business logic called Services, and finally a Data Access layer. The Web application—I've done nothing with it— it's just a template project right now, and same with Test—there's nothing in there at all. Same with Services—nothing in there at all. But following on my conversation with Phil, what I decided to do—at least for the Data Access layer bits here— is to create a very basic model to get started with, and our initial requirements are that we can browse products by category and subcategory and then click on a link and see a product detail. Let's go ahead and take a look at how I implemented the product. This is the only class with any kind of code that does anything. It's important to bring up right now that I don't really need to write code for properties. One of the things you don't want to do when you're writing a unit test is you don't want to be testing the framework or testing something that is out of your responsibility. In this case, the getting and setting of properties is something I don't have to worry about. However, calculating discount amount and discount price is something I do need to worry about. So, taking a quick look at the rest of the objects in the model here, you can see that those are just really simple, property-based objects— nothing special going on there. I've written 2 very basic unit tests inside Visual Studio's Test application. This is pretty basic stuff, and there are 2 things I want to note right here: One—if you notice the way that I've written the name of the test—this is pretty important— you want to write a descriptive name of the test so that when you're reading the test results later— after you have 300 or 400 tests written— it makes sense to you, and you understand what test has executed and passed or failed. The worst thing you can do is to write a test like that. If you have a Product 1 test, you don't really know what it does, and if you're looking at the results sheet, it doesn't make any sense. I'll show you what I mean by that in just a minute. What I can tell you—though—is the way that I'm writing my test is to say, "Well this is what the test is concerning—" the product—, "This is the part of the product that I'm testing—" the discount— and then I'm kind of writing a little clause here that says what exactly I'm expecting, so I'm testing the discount amount, and the price is valid. Pretty simple stuff. Okay, the second thing I want to point out here is that I want to get as close to the functionality that I'm trying to test as possible. In other words, the fewer dependencies and other things that you can get away from, the better. So to underscore that point, I'm going to be accessing all of my data through a repository. I don't want to be using the repository here because that means I have to implement it and do a bunch of other things just to test that I'm calculating this right; that's not something I want to do. All I really want to do is the least path of resistance here, which is to instantiate a new object and then test that the discount amount is being properly calculated. Okay, so now that I've written these tests, let's go ahead and run and make sure that everything fails. The reason that people do this—and they call it red-green refactor— is that you don't want to mistakenly make it so that a test will pass; sometimes that happens—sometimes you might write a test that you didn't think would pass, but it accidentally does because maybe your assertions are incorrect, but you want to make sure the test will actually fail. So, in this case it does, and it's failing because if we go back here to Product, it's not coded up— it's throwing in exceptions—so let's go ahead and add some code to make this work. Okay, so I added some code to just kind of make sure that we calculate it properly. So if we come back over and make sure this builds—and it does— we'll go back to our test, and we'll run the test again; it's important—you want to do this one step at a time. So this is good—we've got a green. So we're going to implement the next part, and to calculate the discount price—it's pretty simple stuff—we're just simply going to return the list price minus the discount amount—easy stuff. Okay, we've done that, and we're going to come back in here to our tests, we're going to run them all again, and hopefully we'll see greens, and we do. Well, that's the end of part one. Next time we're going to get going a little bit quicker. I'm going to start testing out the repository and implement the repository pattern as well as some other neat things. Thanks again for watching. [Questions?][[email protected]] [Microsoft ASP.NET] [www.ASP.net]

Video Details

Duration: 10 minutes and 15 seconds
Country: United States
Language: English
License: All rights reserved
Genre: None
Views: 5
Posted by: neudesicasp on Sep 20, 2013

Rob Conery covers the initial architecture here, in part 1, where he discusses the Repository Pattern with Ayende Rahien and Steve Harman. He also asks Phil Haack what's first: The Test Chicken or the Model Egg.

Caption and Translate

    Sign In/Register for Dotsub to translate this video.