On Mar 21, 2010, at 2:37 PM, frederic gontier wrote: > I think that your approach doesn't match with MVC pattern, because the > controller must be independant from model.
Hi Fred, To who was this directed..? Cheers, Marijn > Your approach links together > model and controller so you create dependencies between them. > A controller can access to multiple objects from multiple classes, and > these objects are not necessary linked by an association. > Your appraoch is good for scaffolding but with more complexe projects > and actions it freeze the MVC pattern. > Best regards, > Fred > > > Le dimanche 21 mars 2010 à 12:57 +0100, Marijn Huizendveld a écrit : >> >> On Mar 21, 2010, at 12:36 PM, Lukas Kahwe Smith wrote: >> >>> >>> On 21.03.2010, at 11:45, Marijn <[email protected]> >>> wrote: >>> >>>> Hi everybody, >>>> >>>> My personal favorite is injecting the required services in the >>>> constructor and use one class per action. This has several >>>> benefits: >>>> >>>> * We don't need to create some kind of convention about routing >>>> arguments overruling service arguments >>>> * Our controllers can be easily tested >>>> * Our controllers are thin >>>> * We can still use inheritance to leverage a base controller that >>>> shares the common methods among the concrete action >>>> implementations >>>> * We can implement this without to much new code >>>> * We don't load heavy controller classes while only using one >>>> mehod >>>> ( yes, Fabien I know, one shouldn't have any heavy controllers;) ) >>>> >>>> Personally I don't see why we should try to make this problem more >>>> complicated than it is. >>>> By using a one class per controller approach we can have this >>>> implemented in no time without any new magic. >>> >>> that does solve the issue at hand. for smaller projects this might >>> be the best approach even especially if you follow the fat model >>> approach. but for larger projects i think this will become a bit >>> painful to manage. >>> >> >> >> What's so painfull about one class per controller? >> I've never experienced that approach as being painful. >> In my current large projects running on 1.X I also use this approach, >> personally I think it is preferred behavior. >> It keeps your controller classes small and easy to read, given that >> most of the methods are available within the file context. >> Add to that decent PHPDoc documentation and a nice IDE and you'll >> never find the need to browse multiple files to understand what is >> going on... >> >> >> Maybe I'm missing the point here but if you use one class per action >> we can inject the dependencies into the constructor and use the >> routing parameters as arguments of the function. >> >> >>> >>> this however is another argument for the constructor way along with >>> some solution to deal with heavy optional dependencies. >>> >>>> I also would like to add my vote to Bernards statement about array >>>> access and __magic__ properties, please don't:) >>> >>> on top of that "__" is sort of reserved for php internal magic >>> >> >> >> Right on :-) >> >>> regards >>> Lukas >>> >>> -- >>> If you want to report a vulnerability issue on symfony, please send >>> it to security at symfony-project.com >>> >>> You received this message because you are subscribed to the Google >>> Groups "symfony developers" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/symfony-devs?hl=en >>> >>> To unsubscribe from this group, send email to symfony-devs >>> +unsubscribegooglegroups.com or reply to this email with the words >>> "REMOVE ME" as the subject. >>> >> >> -- >> If you want to report a vulnerability issue on symfony, please send it >> to security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony developers" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/symfony-devs?hl=en >> >> To unsubscribe from this group, send email to symfony-devs >> +unsubscribegooglegroups.com or reply to this email with the words >> "REMOVE ME" as the subject. > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > > To unsubscribe from this group, send email to > symfony-devs+unsubscribegooglegroups.com or reply to this email with the > words "REMOVE ME" as the subject. -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en To unsubscribe from this group, send email to symfony-devs+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
