There are many ways to interpret MVC in a web context. One of them is to say that all of the actual form processing should be handled in some kind of "action" classes, separate from the controller, which you would then say are a part of the model. (Does it make sense to put these in DBIC table classes? Only if the action is reasonably a method of the object type that class is representing. Otherwise, a separate action class makes more sense.)
Another way to think about it is to say that the "controller" classes in a web framework are already abstract from the web itself and call Catalyst itself the controller and your controller class part of the model. This is a practical point of view and by far the most popular way to do things. However, things like the redirect in your example are obviously web-specific.
The point of all this is separation of concerns and code reuse. Ask yourself, is there any business logic in here that I might want to use from a non-web context, like a cron job? If I did want to, could I do it?
In the example you show here, it fails that test. You have rules expressed here (e.g. you can't create a nation with a name that is already taken) which can't be reused outside of this web context. To solve this, you could create a method (maybe in DB::Nation, maybe in Action::NationManager, etc.) which takes the relevant parameters (name, user, etc.) and either returns a new nation or throws an exception. Your controller code calls it and handles the exception by redirecting.
Sound like a lot of work? It can be. It's definitely worth doing in situations where the code would genuinely be reused, but debatable otherwise. It's up to you to find the sweet spot on the purity <--> practicality continuum for your application.
In reply to Re^3: Help seperating business logic from controller (catalyst/dbic)
by perrin
in thread Help seperating business logic from controller (catalyst/dbic)
by uG
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |