Subtitles of the Movie

Many decisions go into planning a web application and one of the most fundamental decisions is the application architecture. Application architecture is an overview picture of how your application will interact with each of its layers and how your application will interact with the other applications on your site. There isn't one single best way to build an application and the same holds true with architectures. Each project has particular needs and requirements based on the context in which it lives and could need very different architectures. We'll look later at development methodologies which are usually understood as ways to implement your application architecture. An application is generally considered to be a set of related functions. So for example you can have a page where users log in, a page where they create a paragraph or two of text, A page where they can search other paragraphs, and a page that shows the text of the paragraph that they find. Wrapping these functions altogether you would call this a classified ads application. The biggest benefit to looking at the work you are doing as an application is that you'll be able to tell more easily when you have started and when you are done. If you are working in an environment with more than one developer, Dividing work up into applications will allow you to assign particular sets of functionality to other developers. Application architecture then, is figuring out how your individual applications will be constructed so that they can easily be integrated with each other and into the whole of your site, and can be written and maintained safely by different people. Several issues come into play. The size and complexity of applications on your site, and how likely your site is to grow, The number of developers who'll work on an application, how often an application is likely to change And what the development cycle is likely to be. This classified ads application is a good example of a small, relatively simple application. Because it's on a relatively small site, is fairly simple, was created by one person, will be maintained by one person, won't change much, and has a quick development cycle, its architecture is not a compelling issue. However let's say that you had to add to the classified ads. The ability to purchase and renew an ad listing with a live credit card transaction, the ability for users to subscribe to a subscription ad service, that gave a discount based on volume. The ability to restrict edit permissions to users assigned by the main user, tracking of sales of ads based on the state of the user placing the ad and assignment of commissions based on sales from states in a sales persons division. This simple classified ads application will become considerably more complex. In this case then, the architecture of the application would become critical. It becomes even more important when your client contacts you about this fantastic classified ads application you've built and asks you to make it so that users can order and view ads on their wireless phones. If you've used a good architecture, this request would only require minimal changes to your code. The most common form of application architecture is one that separates application layers into tiers. This is usually called Ntier architecture and the N is replaced by the number of layers involved. In this structure applications are generally assumed to have a data layer. For example selecting the user from the database. A business logic layer. For example, should this user be allowed in? And a presentation layer. For example displaying a log in page. The data layer is the database you are working with. So seeing this as a layer is usually straight forward. What's not so clear is the difference between business logic and presentation layers. And if you are working with a site that has ten or twenty applications together, and they all must interact with each other across the layers, the distinction becomes even less clear. Our "Where's Tom" application is a simple, and small application that lives on a site with only a few other applications, and it doesn't need to interact with the other applications. It was written by one developer and most likely will continue to be maintained by one developer. It's not likely to change much, although I do expect to add one or two enhancement to it over the next few months. The development cycle for this application is fast because enhancements and additions are relatively apparent. For this application, architecture is not a major consideration but because being able to upgrade this application for devices other than web page is important. We'll use the most basic construction of Ntier architecture and separate the data from the presentation in this application as much as possible. ge is important. We'll use the most basic construction of Ntier architecture and separate the data from the presentation in this application as much as possible.