"Finding the right place along the continuum can be tricky. When you choose Catalyst over Dancer, you are buying into a set of policies and assumptions."
Using Dancer and any other technology which is not very low level implies a set of policies and assumptions also. "Catalyst assumes that MVC is a good design for your app, that you have a DBMS, that it makes sense to connect the DBMS directly to the web app, and that it makes sense to use the web framework's ORM to do that.". This is not true. Catalyst apps don't need to use a dbms and doesn't asumes that you are using one. Catalyst doesn't promote the idea of connecting to the dbms directly, but it considers that the best idea is to create simple standard Perl modules that can be used with the web app created with Catalyst, or with other CLI programs, or in any other way, so the code can be easier tested and reused in other apps than the web app. Those standard modules could be also used with Dancer or other Perl web frameworks. Only the basic tutorials for beginners explains how to use the Catalyst app as a web app only, because those examples involve only Catalyst and they are easy to understand. Catalyst doesn't have its own ORM, so it can't consider that it makes sense to use that ORM. Catalyst apps can be made to not use a dbms at all, or to use a dbms by DBI module directly, or to use the Perl ORM you choose, depending on the needs. "I chose Dancer over Catalyst because three of those four assumptions are untrue for my app." Because those assumptions are not correct, you need to consider other reasons for using Dancer. :-) --Octavian ----- Original Message ----- From: "Warren Young" <[email protected]> To: "Perl Dancer users mailing list" <[email protected]> Sent: Friday, July 04, 2014 8:53 AM Subject: Re: [dancer-users] Why learn Dancer? > On 7/3/2014 10:07, Andrew Solomon wrote: >> Anyway, I'd like to >> know peoples' views on whether this is a healthy approach to >> developing maintainable web apps. > > Consider this complexity continuum: > > CGI::* < mod_perl < Apache::ASP < Dancer < Catalyst < CMS > > This does not say that everything eventually becomes a CMS, or that > everything is based on CGI or mod_perl at bottom. It just ranks web > frameworks by increasing complexity. The more the web framework does > for you out of the box, the greater the complexity, but also the more > policy it tends to drag along with it. > > Web frameworks occupy a span along the continuum, not a single spot. > Some spans are wider than others. Rails, Django and Catalyst all > roughly overlap, Mason+Poet roughly overlaps Dancer, etc. I show > Apache::ASP to the left of Dancer only because it isn't as big or > complex as Dancer, but in reality, there's considerable overlap. Drupal > is so flexible a CMS that the leftward edge of its span overlaps > Catalyst's space on the continuum. > > At the far left, you are given almost no tools, but you have ultimate > freedom. > > The farther to the right you go, the more your end application needs to > match the preconceived notions that went into the framework. > > Some people try to fight this. They will build something other than a > CMS on top of Drupal, or a non-MVC app on top of Catalyst, or a > non-DBMS-backed app on top of Rails. These are all signs that you > should have started with something farther left on the continuum. > > You can make the opposite mistake, too. If you're building a CMS on top > of Dancer, you're probably reinventing many perfectly good wheels. > > Finding the right place along the continuum can be tricky. When you > choose Catalyst over Dancer, you are buying into a set of policies and > assumptions. Catalyst assumes that MVC is a good design for your app, > that you have a DBMS, that it makes sense to connect the DBMS directly > to the web app, and that it makes sense to use the web framework's ORM > to do that. I chose Dancer over Catalyst because three of those four > assumptions are untrue for my app. > > That is to say, I moved to the left until I stopped violating framework > assumptions. I went no farther left than I had to because I have no > wish to build up my own framework from the stone knives and bearskins > level of technology. > > Dancer is at an interesting position on the complexity continuum. It is > just to the left of the border where features start turning into policy > and design. The best reason to choose Dancer is when you are building > something that isn't already designed and implemented. > _______________________________________________ > dancer-users mailing list > [email protected] > http://lists.preshweb.co.uk/mailman/listinfo/dancer-users _______________________________________________ dancer-users mailing list [email protected] http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
