How should web application interfaces be designed?

I am building a web application, and I was told that using object-oriented programming paradigms affects application performance.

I'm looking for information and design guidelines that come from moving from One Giant to an object-oriented programming interface.

To be more specific: if the web application used OOP and created objects that live for a very short period of time. Will the performance of creating objects on the server be successful using more functional ones (I think static functions are here).

+4
source share
4 answers

Wow, a big question, but briefly (and comments if you would like more information). OOP code / methods (ideally well written on this) will give you much more convenience, readability and joy to encode OGF code.

As for the speed argument, this is really a problem if you are really trying to squeeze all the last possible ounces of the processor out of the server that will clog. In this case, you are probably doing something wrong and should think about the best / more servers or work at NASA or do it for courage.

+1
source

I don't know about performance, but it definitely makes maintenance easier.

I am looking for input and design guidelines that come from moving from One Giant Feature to an Object Oriented Programming Interface.

as David suggested, many pages would be required to answer the above.
Maybe you should take a look at the framework. They make several design options for you.

+1
source

The most popular way to develop a web application with OOD / OOP is to use the Model-View-Controller template. To summarize the 3 main participants:

Model . I work in a problem area that you are manipulating.

View . I am responsible for drawing and managing what you see in the browser. In web applications, this often means setting up the html template and pushing a name-value pair into it.

Controller I am responsible for processing requests coming from the Internet, and figuring out what to do with them, and organizing with other objects to perform this work.

Start with the controller ...

Views and controllers often fall in pairs. The controller accepts the HTTP request, does what needs to be done - and it either does it (if the work is trivial), or delegates the work to another object. Usually it finds a view to be used and passes it to an object that does the actual work of writing the output.

What I described here matches what you expect to find in something like Ruby on Rails.

Creating multiple objects that you use once is certainly a concern, but I would not worry about this aspect of performance. Own virtual machines know how to manage short-term objects. There are many things you can do to speed up your web application - and I would start to sacrifice the benefits of a clear organization for speed, which might not even be the most important optimization ...

MVC is not the only way, there are other patterns like Model-View-Presenter and some really unusual approaches like continuation servers (like Seaside) - which reuse the same objects between HTTP requests ...

0
source

Yes. With the OO approach to developing web applications (using Seaside), I can deliver the functionality much faster so that I have enough time to think about how to ensure the right performance.

0
source

All Articles