armtuk: Cheetah (Default)
So I am building this web app. For the first time, I'm trying to do it by the book. I have a spring context, DAOs and ORM through hibernate. Everything seems copacetic. Then I realize that the logic for stopping a workflow item has to be in two places. So I do the seemingly sensible thing and I pull it out into a method.

A few days pass, and the thought dawns on me that this is what they mean by 'business logic'. An operation that can be called independently of the website to perform a function against the data. The light goes on in my head. The ActionBean should be looking up an instance of this business object in the spring context and setting member variables and calling a method on the business object.

All my functionality like that should be moved into business objects.

D'Oh, Yay! I finally 'get it'. Nobody ever explained how this stuff is supposed to work to me.

This is a subtlety that most MVC guides fail to point out. There is really another level of abstraction there, MVCB, Model, View, Controller and Business Logic. If we were in a SOA this would be the stuff that would be at the other end of the service.

Let me tell you how awesome this is going to make Dot Artistry when I get it going.


Oct. 16th, 2008 09:28 pm
armtuk: Cheetah (Default)
MVC means Model, View Controller. Not Controller who makes a Model and passes it to the View. This is the normal usage of this system in many implementations, but that's not really what MVC is is it? The Model is an independent piece that isn't tied to the Controller directly any more than it's tied to the view. The Controller is responsible for updating the Model, and the view is responsible for rendering the Model.

In a normal Web based application, the Model is in the Database which is often an RDBMS. It doesn't break MVC to have the view talk to the database, because the database is the Model. The big mistake of many ORMs is trying to represent the Model in two places, in the database and in the application server. This of course creates all the same problems as multiple master replication causes for a database product. Every transaction has to be replicated across both systems incurring a huge overhead and making transactions way longer than on a single master system leading to huge performance problems. It's pretty common sense that the best form of distributing load is to have a share nothing cluster where you put different parts of the data set on different nodes. This is in opposition to multiple master replication which puts all the same data in two places. This is good for redundancy, but bad for performance, unless your interconnect is as fast as your local storage, which is rarely the case (don't just think throughput, think latency too). Of course you can do the best of both worlds and replicate and distribute like RAID 10, but this means having homogeneous copies, not heterogeneous copies like relational data and objects.

If we think of MVC as a three legged stool as in the first, we have true MVC, but if we corrupt it, then we get Bad MVC like the second which is like trying to have a two legged stool. It doesn't work too well:

Presenting the Model is the view's job. Preparing the data for presentation is not the controller's job. The controller's job is to process user input and update the model. The model is not a transient object that's instantiated and reads data from a store to a Model object, that's a proxy. The real model is the datastore. Most RDBMSes I know have pretty good methods to update the data within them. Most Models need to do internal checking to ensure that they are sane too and aren't corrupt. This behaviour does not belong in the controller. It's part of the Model. That means database constraints and triggers.

Any framework that forces you to build the Model in the Controller and pass it to the view is a corruption of MVC and is asking for serious concurrency and performance problems. This doesn't mean however that your View cannot be started by a servlet or similar that reads data from the database into a hash and then forwards the display to a JSP or something similar. Just that to do MVC right, your controller doesn't return a Model and a View like in SpringMVC, it might decide which view to send the user to, which will then in turn access the model.

This means that we need different functionality in the view than most frameworks give I think. Some of this can be done in JSTL, but it's kind of clunky.

I'm going to read the rest of the Wicket book in the hope they get this, but I'm doubtful.

Spring MVC

Oct. 6th, 2008 09:11 pm
armtuk: Cheetah (Default)
Took a good look through the new Spring book over the weekend. I was hoping that Spring MVC would be the answer to all my prayers about a web based framework. It wasn't to be. I wish there was something that was between single controller, and portlets. The portlet spec sucks, and the documentation for it is lousy. There's like two books, one is on JSR-268, and the other is on JSR-168, and they both suck. Spring only supports JSR-168 at the moment anyway, and it seems kinda stupid to work with a technology that's already been obsolete for like three years. There seem to be zero docs on themeing, which is like the first thing you want to do with your portlets.

Anyway - I've ordered the newest good struts book I could see in the vague hope that struts has improved since I last looked at it. It seemed like a whole bunch of XML nightmare last time I worked with it that could be achieved with a well written web.xml and dispatcher forwarding (which is what I used in consultant-helper).

Somebody else I talked to recommended stripes, so I'm hoping to get the book on that when I get paid.

I also had got the book on JSF too that I was hoping wouldn't suck, but it doesn't look too hopeful.

It all seems that MVC is just fundamentally wrong. You don't have _a_ model, and _a_ view and _a_ controller. You have input data sets that need processing and then output data sets that all need initializing to render an output that are totally independent of each other. What's in the output fundamentally affects which data you want. One view of the output, say an XHTML page will want all the associated bits and pieces, headers, nav, other things you might like, latest news for this product/item etc. And the XML view just needs the basic data. Somewhere, something needs to know all this and initialize the Models appropriately based on what needs to be in the view. That's right folks, the view needs to drive the model, not the other way around. How else do you explain that pagination is fundamentally a view centric operation, but anybody in their right mind will implement it at the Model level, not the view level, because passing 2000 records through to the view from the database is stupid.

Also - why do we need a separate dispatcher from the web server? URLs are great for telling the system which page you want. Why not keep using them instead of re-inventing the wheel?


armtuk: Cheetah (Default)

April 2017

16171819 202122


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 23rd, 2017 09:22 am
Powered by Dreamwidth Studios