 Okay, so, this is the time table for today. We've got a long session again to begin with, 1911, where I'm going to be talking about the overview controller design pattern, and then Mark Elvigo is going to be talking about JPC. We've got a bit of a theme today in terms of looking at software design patterns. So, that's, I'm going to give you an overview of MVC on the controller, which is obviously an important design container in quite a lot of conditions, and Mark Held is going to be talking about the appropriate side to use my interactivity on a base basis. Following on from that, we have got our session with ThoughtWorks, where they're going to be giving us a workshop set up, some practice in agile practices in the context of work development, and then we have a free lunch, which we're inviting to attend, so that's going to be in here. So, that's going to be from 12.30 to 1.30, and then after that, we've got introduction to the laboratory exercises for this afternoon. So, that's going to be the application of MVC and JDBC, so you're going to get some hands-on experience doing that, both in the first lecture session in the afternoon and obviously in the labs later on. Now, the other thing is, we've got our first demonstration in the lab this afternoon, so the first exercise to be assessed is section 0. So, if you haven't done some already, can you make sure that you submit that to Blackboard, so you haven't got to do that? The reason for this is not so that we can mark your work offline, so we're not going to pretend that. It's all going to be marked by demonstration. The reason for this is because partly because students supported this policy for the Federation Association, so we're working together, but also so that you have easy access to marks and also system written feedback as well. We should give you some verbal feedback during the demonstration, but we've got a two-and-a-half-hour lab session, so that'll be an opportunity if you need it to get feedback on any problems that we have in the lab and how you can do better next time, and we're going to be putting that into Blackboard as well, so you'll be able to access those comments through Blackboard. So, hopefully that's a helpful book. So, I know there's some confusion about this last week, but I think that's going to be great for you to know. Right, let's get on. Model view controller, MVC. The subtitle of this is, What can it do for me? So, I think it's quite easy when we're talking about the MVC design, but it needs software architecture. So, get bogged down in the semantic. It's very easy to worry about how exactly it should be applied in a pure form, and that's not always the most helpful way of looking at a model for a development perspective. So, hopefully by the end of the lecture, we'll have a good idea of how the model view controller program is useful in web application development and how you can think about using it yourself. So, I'm going to briefly describe the origins and the history of MVC, and it's so helpful to know where it's come from, what goes where. So, then we'll be talking about what parts of your application, what parts of your code might go in the model, what parts might go in the view, and what parts might go in the controller and how those matter. Then we'll talk about how they were taught to each other. So, how should the model view and the controller interact with each other? Interface communicates. Very importantly, let's talk about why it's useful. I mean, hopefully that's going to come out over the course of the lecture, so it's not just going to be something that we didn't get to at the end. There is a benefit by tree-vay brain scale. There's no one in the region in the region. I don't know if I said that correctly. I think that's how it's supposed to say it. It started life not as a software architecture, but basically as a set of design metaphors that brain scale thought would be useful for applying to the design planning of complex construction projects. So, that's kind of where it comes from. You start to think about this in 1973, and, in fact, later on at the end of the slides for some links to the original papers and stuff, you can have a look at those. They're quite interesting to me. In 1979 it was applied to the Small Talk 80 language, so it's written into the class slide we've got, as an architecture specifically for GUI applications. In fact, it wasn't made to go and did this. It was when his colleagues at Xerox Park, where this all happened, Jim Acton, I think, was. That's when it became so that papers have been written about this, and this is kind of the original software architecture paper. Again, this is a very accessible paper, so I recommend reading that. The idea of the pattern is to decouple data access and business logic from the presentation to the user. The model is responsible for managing its date, managing the dates that it contains, and the view is responsible for presenting part of the model to the user at any one time. I'm not sure that's a brilliant image to use for the controller, but it's not really a controller. The controller is responsible for managing user inputs and routing that to the appropriate part of the model. The model receives instructions from the controller, and it may also be contacted, I suppose, by the view in order to update what's shown in the view. We'll talk a little bit more about how these fit together in the next few sites. In the model you have data. We have operations on data. We have rules governing access to and updates data. Now, is this making sense to open project? Yeah? What happens in the model? The model is basically like, decide your application, sort of is your application, and the view and the controller are ways of interfacing with it from the outside, whereas if you're tangible, I think, it's a representation, a visual representation if it doesn't have to be, part of the model. It specifies how the model should be presented. The view code is, look at part of the model and specify how it should be presented to the user. A couple of ways this can happen, the data from the model can get to the view. The push model, the view listens for change notifications from the model. We'll also see later on a controller and a direct review as well. This is in terms of the data, the state of the model. The view to listen for changes, alternatively, the view can call the model to get its most recent state, includes current state, and that's the call. What happens in the controller? This is responsible for dealing with user input. This translates user input, actions, interactions from all. This requests, so it takes a request and sends it to the appropriate parts. It may also select a new view. It may also tell the view what to display next. We'll look at how these things interface later on. That's one of the other things that I do. Let's clarify how the supplies to web applications originally applied to web applications. What does it mean for web applications? Before we go any further, I just want to ask at this point, how many people in here are really both fair with NBC, very happy with it, and how it should be applied to software design? How many people have done that? I've heard of it, but I'm not too sure. How many people are like, what are you talking about? If you're not familiar with this paradigm, it doesn't necessarily put you at a disadvantage. It can often be more difficult if you have a preconception which is a bit fuzzy. It can be more difficult to get rid of that. I haven't heard of it before. As some of you may have spotted, it only seems about separating concerns. It's an application of the separation of concerns. In particular, we've got the dialogue with clients, which is the front-end of our application, the internal day for operations, which is the back-end of the application. I hope these don't make sense to the public. We can also see a really nice map into the HTTP-induced supply cycle, getting the validator request for the first stage. What would that map do? What would it do so far? Execute the request internally, where is that map? Is that map? Yes. And compose and return this one. Right. Let's think about how they fit together. The browser on the left-hand side, and that sends a request to the controller. The controller then says, okay, we've worked out what to do with this, and I'm going to contact the model with these parameters on what to do. The model does its stuff. It may notify the controller when it's finished on forecasting message. At that point, the controller gets the chats with the view, and the controller says, okay, I also know from this HTTP request that what we want to do is display this page next. You know switch between them. Finally, the view says, okay, I know which template I'm going to be using, and I know what content to put in there. So I'm going to get the data from the model. So the view contacts are modeled to get the data. And finally, of course, this is all displayed in the browser. Does anyone have any issues with that? Have you been making sense? Anyway, disagree with that way of doing things? I'm quite, feel free to shout out, by the way, if there's anything to this that isn't clear, because I think we can move it. Let's look at another way. So in this particular diagram, we're going to have our request starting in the view. So the input goes into the view and the view says, okay, we've got this request. I'm going to send it off to the controller and the controller can work out what to do with it. I'm going to control the contacts of the model again. I'll just send some data back. And the controller then sends me directions to the view. Now in fact, in some software protection, this is where it finishes. So the controller does all of the mediation of the model and the view. But of course, that may not happen. It may be that the view is registered with the model. So it receives notifications about many changes. Or it may be that it contacts the model and it receives some data back from the developer's current state. So it's flexibility within the system. It's known one way that you have to do things. It kind of seems for web applications that you've got that model both client side and out. Yeah, yeah, absolutely. Yes, that's true. So obviously you can think about it as a kind of overall software architecture. But also you've got the design pattern that can go through the client side and the service side. So the new experience is of using that using the paradigm yourself. No, not in this technology. Right, okay. Yeah, that's a very good point. So obviously we're kind of talking about this as an overall, this is how you might use the entire application. But in fact, we've got some subsets of the pattern applied throughout the application. So actually looking at this and going back to what you're saying. So if we're talking about client and service side code, the main point could be either. If we're viewing this as our overall application, which of these bits would go in the server? Which server side code? I think definitely the model. And most of the controller, I think. Yeah, yeah, I do think that. What's about the view? Can you about the go in there? Well, of course it should be on the client. But I don't know. Sometimes, actually, they have to be shared on both on the client and the server. It depends on how you deploy some things. Yeah, absolutely. That's very, very true. So, I mean, in fact, you may have, obviously, some of the view on the client side. You may have the view on the server side as well. You put it on the server side too, probably, in order to do things like create the pages to begin with. But, of course, yes, any client side scripted the view of the client as well. But like you say, it's not hard and fast. It's not fixed the way that you set these things up. So, we talked about a couple of things that the model, the view, the controller can interface. In fact, there are lots and lots of ways. These are just a few of them. Chosen for no particular reason, they're all slightly different. So, I think it's important to make this point. There are lots of different ways that you can apply this. It's not necessarily the case that one is better than the other or that one size fits all. So, just thinking again about the application to web applications in particular, why is it useful to use this particular paradigm of thinking about our application but separating our concerns? The idea of separating things into the view, the controller, the front end, the back ends. How is that particularly useful for web applications? For the user experience? For the user experience? Yes, absolutely. One of the reasons it's useful is because you can get people different developers. So, from a practical software engineering perspective, you can have different developers working on the front end and the view codes and the back ends and the database access and the business logic. So, obviously, that's where you use one and maybe the developers have different skills. So, some will be better at front-end programming than others at their background programs. That's a really good point. Is a web application more likely to have to be able to need to change its view than another kind of desktop application? Yeah? Yeah, so, obviously, you might have a view for a particular browser. You may have to change slightly for different browsers although hopefully you may be using a framework to help to handle that. But, obviously, if you want a mobile version of the application, that may have to be quite different from a desktop version. So, you don't want to be writing an entire new application for a mobile phone. Well, it does happen sometimes. But anyway, that's a good reason to think about using this kind of paradigm. Right, so, let's think in a little bit more detail about where different parts of our code might go. So, let's think about data validation. Now, I think I said in an earlier slide the controller getting and validating HTTP were quite a source. We can have our validation code in the controller. Should we always go in the controller? How about data sanitisation? So, this is something we talked about last week. This is where we look at the code that the input that the user has given us and make sure it's not JavaScript or something horrible like that that's going to attempt to compromise our programme. Where would you say that the sanitisation code should go? In the controller? Does everybody agree with that? It could be part of the view as well. Yeah, it could be part of the view as well. So, it depends how you've got things set up. So, in the couple of diagrams we looked up for, we have one where the browser just got in touch with the controller straight away and that would be an appropriate place. So, the controller would be an appropriate place to have the sanitisation code then. Obviously, in the second one the view was dealing with user input directly and forwarding that to the controller. So, that would be the place where you can put your sanitisation code. What about user authorization? Where would that go? The controller. The controller? Anybody? Anybody? Anybody? Yeah, so this is something you really need to think about from a security perspective. So, again, it depends how things are set up exactly. You are restricting access to your model, restricting access to your database in particular. So, we talked last week about how the database would be, hopefully, separate from the model in terms of the way it's accessed. So, access to the program that we need authorisation to do that. You need to make sure that you don't authorise your users too early in the process and compromise access to the database. So, if it's useful, I think, sensible to have authorisation code, perhaps in the model and possibly in the controller response. What about other types of filtering or validation? So, say, for example, you have a food delivery service but you only deliver within a five-mile radius. So, one of the first things you do when a user comes to your site to get me to put in their postcode so that they can check when they will actually deliver food to them. So, that's another kind of filtering or kind of validation. Where would you have that code? Where have we seen a sensible place to put that kind of check? In the controller. In the controller? Yeah, you can have it in the controller. Yeah, absolutely. I mean, arguably, it's part of your business logic. I mean, arguably, all types of filtering are part of your business logic. So, your model kind of decides what is able to access it. So, from that perspective, just so that it should go in the model. Now, I'm not saying it necessarily should and I guess this is the point. But it might be sensible to put in the model if you want it to be scalable and it turns out that actually you're saying, for example, you're only delivering in one area at the moment but it may be that you want to go across the country but they're going to be different centres, dealing with different parts of the country. The postcode is still important. But you're having to implement kind of different... Whereas you could have just one part of the model dealing with it, you're having to implement different controllers and different views for different parts of the country. It doesn't make as much sense. So, anyway, the point is... The themes are all done to that particular part, but the point is it is a really good idea to think part about where you're going to put bits of your code. Whether or not from a kind of design perspective they go in the model of your controller is really down to the design of your software. So, again, we're coming back to this issue of NBC's a sense point to think about things, but it's not kind of hard and fast design rules. It's important to think about separating concerns sensibly rather than trying to apply the perfect form of empathy. Right. So, let's think about frameworks for a minute. The reason I'm talking about Ruby on Rails is obviously not because we're using it, but because it describes itself as opinionated software. Has anybody used Ruby on Rails in here? No, okay. So, it's very... very keen on encouraging what it considers to be best practice amongst the software engineers using it. It works mainly according to the dry principle. Who knows what the dry principle is? Do not repeat yourself. That's right. Do not repeat yourself. What's that? Has anybody heard of the case principle? Yeah. Keepers. And it packages its code into very tightly controlled parts. So, we've got the action pack here, which contains the action controller. Can we guess what that relates to? And the action view. And then active record contains its database. And it's more... So, we've got some other framework users in the room. I haven't wait. Strat... Strat's. You're using Strat's? I'm right already. It's a customized version. Okay, so you have this customized version. Do you, within your customized version, apply the MVC paradigm? What do you say? You have a kind of a controller. And we have a kind of a... What do you call it? A data object kind of thing. That's what the, you know, the model side of it. Write all the systems logic there. And you have, again, a kind of a data, a few kind of an object is being passed to the front-end side. Yes. Where it is getting displayed on. We have a set of beams, which have all the set of classes for the front-end display and other data. Yeah, so basically you're applying the paradigm but within your specific context. Okay, in the way that you need to. So this is the thing. There are often different ways of applying it, but it can be very useful to think about separating your concerns in that way. So, sorry, somebody asked, was it Spring or Strat's? Spring. So how is the MVC applied in Spring? There is a part of the Spring called the Spring MVC. Right. Which is responsible for handling the MVC pattern. And for the controller and view, it's somehow the same as you described. But for the model, it's using Hibernate for the managing database. Right. So is it with something like Spring, do you have to use MVC? I mean, sort of Ruby, you really pushed into it. But I know that other frameworks are a bit more accessible. No, you don't have to. But you can use the Spring MVC packages. Yeah. And do you use them? Do you find that a useful way of organising them? I use them. Okay. Is anybody else who has kind of hard experiences in frameworks? I have used both of these two with the JSP. Yeah. But let me like the fact that you have to add JSP code inside the schema pages. Right. And this is not part of the MVC. Yeah. If you want to do this, you couldn't work. Right, okay. So this was very bad. Yes. And I also used parts of the JSP framework. Yeah. Which was really in order to maximise the MVC pattern. Yes. And you can't put JSP code inside the framework. Yeah. So which do you prefer? Of course, parts of the MVC. Ah, there you go. So we've got lots of votes here for MVC. So if you can use frameworks that do and don'ts and implement it. And you find that the MVC version is the easiest one to use. Okay. What's the easiest one? Okay. But the fact that it doesn't allow you to add JSP inside the schema. Yeah. It maximises the MVC pattern. Yes, yeah. And do you think that's a... Do you find that's a bad way of organising the software? Yes. Because if you use JSP in strikes, you will have to add JSP. So you can separate the concepts. Yes. Yeah. That's a very interesting point. So the thing about frameworks which I think is brought out here is that they essentially mean you don't... Well, depending on the framework. You don't have to worry about how you apply MVC because the framework's doing it for you. So it's just one of the points of using a framework. Obviously give up some flexibility, but they enforce generally good software practice. Now people have their opinions about which ones they like to use and which they don't. But most of the time, they massively accelerate the development process because they don't require you to think too hard about what you're doing. We're going to require you to think about what you're doing, by the way, just to see that. So we are going to be using a framework later on. But it's one which has quite a lot of flexibility there. Okay. So it is not the case that you just apply MVC to software architect necessarily. As we talked earlier on, you can subdivide your application and apply MVC perhaps to the client side and perhaps to the server side. You can also apply it to things like user interface development. So this is relatively recent work. This is some research that's being done in our lab at the moment. So inside the model of your user interface, you have your data or information and the constraints on it. So when I talk about data, we're talking about the data types here. The data types are that you're using and how those data types are constrained and how they can interact. And inside the view, you're basically talking about the structure of the user interface that you're using, different components, user interface components, and how those all fit together in the screen. And the controller covers the user interface behaviour. So this is basically how people interact with the application and how the user interface behaves in response to them. Is this making sense to people, or is this not? That's more like a smart client using local good spectators. Oh, okay. It's also to increase speed. Right, so what is it that you're doing in your... It's a large scientific data model for the manipulation and extracting 2D, data from 3D, and 4D, 5D, and 2D data. So you do that. It sounds like it breaks the only synch pattern, but you do that on the local... Oh, right. ...to take you along a long time. Yeah, okay. Oh, that's interesting, actually. So you're applying... Is this kind of way of breaking up the... Yeah. Okay, all right. So I didn't know that it was kind of applied directly in that way. The way that we're looking at this in our lab at the moment is to do, obviously, to map an user interface as a service. Now you're applying it. Yes, it's interesting to have industry applications. And this is to do with... The research is to do with trying to understand how to build better user interfaces. And at the moment, our colleague of ours, George Obrachanir, is trying to develop a tool that can help tell you how to design your user interface based on the controller. So based on the way that the user interacts with the software. It's quite complicated, but there are a few people working in this area at the moment. Right. Why use MVC? We've touched on a couple of examples already. Okay, so one of the obvious reasons is, obviously, it makes it easier to develop your code. So from a software engineering perspective, you can have different people working on different parts of the application. And then, as long as you define the interface correctly, those parts can be encapsulated and people can do what they're best at doing, hopefully. And then you can fit the parts together with the minimal fuss. Obviously, it also makes it easier to test your application. So if you, again, have separated concerns sensibly, possibly a bonus based paradigm, then it means you can test them in isolation. And, again, you shouldn't have too many problems with false money impacting on another. And, of course, for that reason, it's easier to maintain as well. These things all apply to MVC, but they just apply to separation concerns, right? So the ones that you separate sensibly should have all of these benefits. So the benefit of MVC in particular is it provides for you as a web application developer a way of managing the complexity. So if you're doing the complex application and you're trying to work out how you should separate your concerns sensibly, then applying MVC just gives you a way of starting to think about that. So that's the particular benefit of this paradigm. And, in fact, of course, with frameworks, they do a lot of that thing for you. So just look at MVC and practice. I just realised, if you can't tell at the moment, but I think the slide looks slightly circular when all of the points are written down. So I'll try to make sense of those as we go through. OK. If you're using a framework, you don't have to worry about things like what's going on a lot more, what goes in the controller, what goes into you, necessarily. A lot of the framework will do that for you, and it'll tell you what to put where. I know for some frameworks that to be flexible and you can kind of decide what you want, how you want to organise things yourself. But it can take that issue away from you. And again, it defines how they draw to each other. So most frameworks need to define how these things interact. If you're not using a framework, or you've got a particular spoke application that you don't think is going to fit well into a framework, then you start up with and you can use the best way to separate your concerns. But to start, how do you manage complexity? Right, so I've got any questions relating to what I've just been talking about. Is this completely clear to everyone now? Yeah? I've got some people nodding, they're mostly the people who knew about it. So later on in the labs, you're going to be getting an opportunity to think about how you should apply this to dictionary zero in doing it over the last week. It's going to do some applying embassy in practice. And this morning, ThoughtWorks are going to be talking, they're not going to be talking about embassy, they're going to be talking about quite a different part of software development. But I think it would be interesting when they're talking about the agile practices you can use for software development, and how you might think about things like incremental design, which is something you're going to talk about. How that maps to software architecture in the way that we've been thinking about it, and how it might map or not the entity paradigm of where you separate concerns. So I think that's something interesting to think about as we're going through that section. Right. Fortunate you don't have to listen to me in the first session, because Mark Hell is going to talk now about JDC.