Error handling in MVC
What are the recommended approaches for dealing with errors that arise in the Model (observable/subject/publisher) piece of an MVC architecture? For example, if an error occurs in the Model during a database update that resulted from a database access initiated from View to Controller to Model, how is that error propagated back to the View? Does the View wait for a response from the Controller, which in turn waits for a response from the Model? In this case I am not using a web interface, although I don't really think that is very relevant. Thank you!
[565 byte] By [
andy786a] at [2007-10-2 23:09:52]
All errors are caught and handled by the Controller, of course. It might tell the View to display an informative message telling the user what happened and what to do next, but everything happens under the guidance of the Controller.This is true in both Web and destop MVC.%
> All errors are caught and handled by the Controller,
> of course. It might tell the View to display an
> informative message telling the user what happened
> and what to do next, but everything happens under the
> guidance of the Controller.
How is the Controller notified of an error that occurs in the Model? Is this contained in the return value from the public (interface) method that is called by the Controller against the Model object? And how is the View told to display an error message to the user? Is this in the return value from the Controller? For example, the user click on the "save" button, and controller.save(...) is invoked; the Controller then invokes model.save(...); if there is a timeout from the Model (e.g., the database not responding) then a status is returned from the Model to the Controller, which then passes that status on to the View?
> How is the Controller notified of an error that
> occurs in the Model?
I said "caught", which suggests that an exception has been thrown. That implies that there is no recovery actions to be taken, and the Controller needs to inform the user that something failed.
> Is this contained in the return
> value from the public (interface) method that is
> called by the Controller against the Model object?
It can be, but that's a C-style of notification. You can ignore return values, but you can't ignore exceptions.
> And how is the View told to display an error message
> to the user? Is this in the return value from the
> Controller?
The Controller passes the appropriate message to the View asks it to refresh itself.
> For example, the user click on the
> "save" button, and controller.save(...) is invoked;
> the Controller then invokes model.save(...); if
> there is a timeout from the Model (e.g., the
> database not responding) then a status is returned
> from the Model to the Controller, which then passes
> that status on to the View?
Yes. That works.
MVC has evolved a bit since the original Smalltalk work. Nowadays it looks more like this:
View->Controller->Service->Model->Persistence
The Controller asks a Service to do all the work. The Service has Model and Persistence objects that it uses to accomplish a task. Instead of the three-tier architecture it's more like a 5-tier or n-tier architecture.
%
%
> View->Controller->Service->Model->Persistence
>
> The Controller asks a Service to do all the work. The Service has
> Model and Persistence objects that it uses to accomplish a task.
> Instead of the three-tier architecture it's more like a 5-tier or
> n-tier architecture.
Indeed. They used to draw the mechanics of the MVC pattern as a little
triangle: an M, V or C in each corner. This implied that a V could talk to
an M (and vice versa) directly. Decoupling the V from the M by leading
all 'traffic' through the C is much better IMHO.
I normally think of an M as a proxy for the persistence layer so I don't
make the distinction 'model <--> persistence'. I also usually think that
a C *is* the service (the C may delegate the business logic to some
other plugable bunch of objects though), but I *do* distinguish more
"V like C bizniz" from the more "M like C bizniz", so I always end up with
five distinct tiers/parts etc. also.
kind regards,
Jos
> Indeed. They used to draw the mechanics of the MVC
> pattern as a little
> triangle: an M, V or C in each corner. This implied
> that a V could talk to
> an M (and vice versa) directly. Decoupling the V from
> the M by leading
> all 'traffic' through the C is much better IMHO.
I agree.
The only point that I still waffle on is DTOs and the role they should play.Some people are adamant about not passing Model objects to View (JSPs), because they say this breaks layering. The solution they propose is to come up with a parallel hierarchy of DTOs, which have the same attributes as their Model counterparts without any functionality - little more than C structs.
I think the important bit about isolating View is that it should never reach around the Controller to do anything meaningful - no calculations, no database access, no business rules or logic of any kind. If you can do that without enforcing the idea with a DTO hierarchy, I say it's OK for the Controller to pass Model objects to View. All the View should do with them is display state.
> I normally think of an M as a proxy for the
> persistence layer so I don't
> make the distinction 'model <--> persistence'.
From the point of view of the View, that's true. It has no way of knowing whether that Model object persists or not. For all it knows, the Controller has a huge memory store from which it magically pulls whatever is needed. Sounds like a "Santa Pattern" 8)
>I also
> usually think that
> a C *is* the service (the C may delegate the business
> logic to some
> other plugable bunch of objects though), but I *do*
> distinguish more
> "V like C bizniz" from the more "M like C bizniz", so
> I always end up with
> five distinct tiers/parts etc. also.
I like having separate Controller and Service layers now because of frameworks like Struts. If you put all your logic in their Action class it's frozen there - no one else can get at it, and you can't use it without Struts. Spring encourages separate Controller and Service layers. I think it might help with a service-oriented architecture (another loaded topic), because now you can expose anthing in the Service layer to clients outside your app. No View involed.
Always a pleasure, Jos.
%
PS - Good luck to Netherlands in the World Cup. USA is just going home.
[ snipped the previous bits because we simply agree on those parts ]
> >I also usually think that a C *is* the service (the C may delegate the
> > business logic to some other plugable bunch of objects though),
> > but I *do* distinguish more "V like C bizniz" from the more "M like C
> > bizniz", so I always end up with five distinct tiers/parts etc. also.
>
> I like having separate Controller and Service layers now because of
> frameworks like Struts. If you put all your logic in their Action class it's
> frozen there - no one else can get at it, and you can't use it without
> Struts. Spring encourages separate Controller and Service layers. I
> think it might help with a service-oriented architecture (another loaded
> topic), because now you can expose anthing in the Service layer to
> clients outside your app. No View involed.
w.r.t. your first sentence: I like to put all the nitty gritty work in POJOs
but I've never considered that a separate layer ... and indeed, if you're
sticking that work in the 'technicality' classes, like Actions or worse, EJBs
you'll end up with your business classes glued to the nuts and bolds of
the technology you have to work with.
Spring does help in actually implementing that separation (it took me a
long time to realized that ;-)
I still 'smuggle' a bit though, i.e. I stick in some meta data in the produced
models to help the views a bit ;-)
> Always a pleasure, Jos.
likewise,
kind regards,
Jos
> PS - Good luck to Netherlands in the World Cup. USA is just going home.
Thanks; I think we can beat Portugal tomorrow but after that I think it's
over. The Dutch players are lazy (*), when they think they can afford it
they come to a shrieking halt and then suddenly: *boing* they're one or
two goals behind and never catch up again ...
(*) nothing bad about laziness by itself though ;-)
> w.r.t. your first sentence: I like to put all the
> nitty gritty work in POJOs
Right. You have a choice then about how you wrap and deploy it :servlet, EJB, web service - they all just defer the work to the POJO.
> but I've never considered that a separate layer ...
> and indeed, if you're
> sticking that work in the 'technicality' classes,
> like Actions or worse, EJBs
> you'll end up with your business classes glued to the
> nuts and bolds of
> the technology you have to work with.
Exactly. I've never liked that. When I see servlets and EJBs with long, complex methods I shudder.
>
> Spring does help in actually implementing that
> separation (it took me a
> long time to realized that ;-)
I like Spring very much. I think it encourages a lot of good object-oriented/Java practices. It's as big a benefit as all that nice plumbing code they provide.
> I still 'smuggle' a bit though, i.e. I stick in some
> meta data in the produced
> models to help the views a bit ;-)
I wouldn't object to meta-data; it's the behavior that's a problem.
> Thanks; I think we can beat Portugal tomorrow but
> after that I think it's
> over. The Dutch players are lazy (*), when they think
> they can afford it
> they come to a shrieking halt and then suddenly:
> *boing* they're one or
> two goals behind and never catch up again ...
>
> (*) nothing bad about laziness by itself though ;-)
Spain and Argentina are looking awfully good. Then there's the home country. Wouldn't they like to celebrate in Berlin? And if Ronaldo has awakened, and Brazil has been playing to the level of their competition, everyone else has to watch out.
%
> > w.r.t. your first sentence: I like to put all the nitty gritty work in POJOs
>
> Right. You have a choice then about how you wrap and deploy it:
> servlet, EJB, web service - they all just defer the work to the POJO.
So I noticed by experimenting with that 'paradigm' a bit; it feels like a
safer haven where you can go and design/program whatever you want
to design/program without being hindered by all those funky rules you
have to obey to otherwise.
> > but I've never considered that a separate layer ...
> > and indeed, if you're sticking that work in the 'technicality' classes,
> > like Actions or worse, EJBs you'll end up with your business
> > classes glued to the nuts and bolds of the technology you have to
> > work with.
>
> Exactly. I've never liked that. When I see servlets and EJBs with long,
> complex methods I shudder.
I never liked EJBs; IMHO it's a technology on the move where they still
haven't found the 'ideal' way of doing things. I think the same about the
WEB side of this all: all those technologies, all those different versions,
all that browser mess with its Javascript hacking and now AJAX coming
up. If I had it my way I'd simply wait a bit 'till things have settled a bit
more; a bit more agreement about the 'right' way to go ...
(I'm not very good at all that jsp/javascript/html/xml stuff ;-)
> > Spring does help in actually implementing that separation (it took
> > me a long time to realized that ;-)
>
> I like Spring very much. I think it encourages a lot of good object-
> oriented/Java practices. It's as big a benefit as all that nice plumbing
> code they provide.
It took me a while before I understood what all that 'work flow' was all
about. A few hours of digging in the source code made me understand
what I couldn't understand from the documentation: all those preposterous
long names like 'SimpleUrlValidatorMapperHandler' obfuscated what
it is all about (at least to me it did ;-)
[ the most important part: soccer ]
> Spain and Argentina are looking awfully good. Then there's the home
> country. Wouldn't they like to celebrate in Berlin? And if Ronaldo has
> awakened, and Brazil has been playing to the level of their competition,
> everyone else has to watch out.
Those Brazilians are real ball jugglers, the Dutch are not up to that.
I think by the end of next week all those loonies that have painted
everything orange can remove that paint again ;-) I don't think Germany
is going to win either; their tactics are too 'rigid'. My bet is Spain, Brazil
or Argentina ...
kind regards,
Jos
.> So I noticed by experimenting with that 'paradigm' a
> bit; it feels like a
> safer haven where you can go and design/program
> whatever you want
> to design/program without being hindered by all those
> funky rules you
> have to obey to otherwise.
Not to mention easier to test. I'm using TestNG these days and liking it very much. IntelliJ pops out the TestNG skeleton for every class I need to test, so there's no excuses about writing them. I love it.
..> I never liked EJBs; IMHO it's a technology on the
> move where they still
> haven't found the 'ideal' way of doing things. I
> think the same about the
> WEB side of this all: all those technologies, all
> those different versions,
> all that browser mess with its Javascript hacking and
> now AJAX coming
> up. If I had it my way I'd simply wait a bit 'till
> things have settled a bit
> more; a bit more agreement about the 'right' way to
> go ...
> (I'm not very good at all that
> jsp/javascript/html/xml stuff ;-)
Me, neither. 8(
I'm a bit worried about SOA, too. Distributed objects again? How is this different from CORBA? I fear that we'll archtect these beautiful, flexible, but slow castles in the sky.
.> It took me a while before I understood what all that
> 'work flow' was all
> about. A few hours of digging in the source code made
> me understand
> what I couldn't understand from the documentation:
> all those preposterous
> long names like 'SimpleUrlValidatorMapperHandler'
> obfuscated what
> it is all about (at least to me it did ;-)
My favorite is AbstractTransactionalDataSourceSpringContextTests. Now THAT's a class name!
.> Those Brazilians are real ball jugglers, the Dutch
> are not up to that.
> I think by the end of next week all those loonies
> that have painted
> everything orange can remove that paint again ;-) I
> don't think Germany
> is going to win either; their tactics are too
> 'rigid'. My bet is Spain, Brazil
> or Argentina ...
>
> kind regards,
>
> Jos
Germany was ahead of Sweden 2-0 when I left the house, and they were only 17 minutes into the game. I'm looking forward to seeing Argentina and Brazil, that's for sure.
%
> Germany was ahead of Sweden 2-0 when I left the
> house, and they were only 17 minutes into the game.
> I'm looking forward to seeing Argentina and Brazil,
> that's for sure.
Mother Mary and Joseph, I thought the game started at 9:00pm.
Back later ;-)
kind regards,
Jos
> Thanks; I think we can beat Portugal tomorrow but
> after that I think it's
> over. The Dutch players are lazy (*), when they think
> they can afford it
> they come to a shrieking halt and then suddenly:
> *boing* they're one or
> two goals behind and never catch up again ...
>
> (*) nothing bad about laziness by itself though ;-)
It will be another fantastic game! I don磘 think Netherlands players are bad. Arjen Robben is a very, very spectacular player, and very dangerous, too, that is able to decide a game only with his talent! Someone must break his legs to stop him (kidding...)! Nistelrooy is an excelent player, too, but I think he hasn磘 shown all his potential in this cup yet. It even seems that there is something not normal with him, I don磘 know. Something like Ronaldo磗 case, who is finally demonstrating why he deserves a place in brazilian team. But I磎 sure that when Nistelrooy starts showing all his prime football, nobody will be able to stop him.
England-Ecuador is scoreless. Into the 2nd half.%
