企业Web应用程序体系结构问题

Question

I am wondering if it would be possible to develop an enterprise-level web application without the use of a standard MVC structure and application server by carrying the business/flow logic and session data to the client-size Javascript and make it talk to REST data services directly...maybe we could make use of an authorization/authentication layer and a second validation layer sitting on top of the data services. All these services operate on standard HTTP methods, support configurable logging&monitoring, and content or query parameters are all contained in the HTTP request/response body. Static HTML and Javascript are served to the browser and the rest is carried out by Javascript functions talking to the HTTP-based authorization/authentication, validation and then data services. Do you think this kind of an architecture could satisfy enterprise-level web application requirements?

Answer 1

Its possible but unlikely; what are the drivers that suggest this architecture to you? Is it just to be different or are there some specific aspects that this best addresses?

by carrying the business/flow logic and session data to the client-side Javascript and make it talk to REST data services directly

In theory you'd still be able to have an appropriately layered solution (Business Logic (BL) script vs UI focused script) but practically speaking it'd be messy; and you'd lose the ability to physically separate it into different tiers. This could "bite" you at any number of places in the life of the system.

"Enterprise" grade systems are seldom small, I hate to think how much logic you'd be having to send over the wire to support a given action / process.

Putting all the BL into a scripting language ties you to that platform, and platforms change overtime. The bad thing about scripts is that whilst they are stable to a degree I'd suggest they are more exposed to change than server based platforms like Java or .Net. In an enterprise scenario the servers will have very tight change control and upgrade paths mapped out for them - where-as browsers are much more open to regular change.

There's the issue of compatibility - unless you're tied to a specific browser (to the version level) guaranteeing consistent behavior is going to be harder, and will likely require more development effort. Let's say you deliver the solution successfully; what do you do when the business wants to take advantage of mobile computing - say iPads? Your only option is going to be a browser - you won't be able to take advantage of any of the native advantages of the platform. "The web and browsers" might seem like they'll be around forever - but then I'm guessing that what MainFrame folks said at the time. A server centered solution is going to give you more life for less expense.

Staffing will be an issue - you'll need very strong JavaScript and server-side developers.

Security: having your core BL out on the client where it's much more exposed sounds very dangerous.

EDIT:

Web Apps can be sow for many reasons - not many of which are reason enough to put all your BL in JavaScript on the client. Building apps for performance is a whole field of endeavor on its own - I suggest you get more familiar with Architecting and implementing for performance for before you write-off n-tier web apps altogether :)

Regarding keeping your layers separated: there's different ways of doing this but it boils down to abstraction - and more correctly to keeping good design principles in mind; if you haven't heard of SOLID that would be a good place to start. In terms of implementation start reading up on Dependency Inversion (FYI - self promotion, the articles mine and is .Net focused, but you should have no problem tracking down Java based ones too).