Hi Bill, On Mon, Jan 2, 2012 at 11:41 AM, Bill Moseley <[email protected]> wrote: > > So, I'm looking at adding a separate model layer(s) ("pattern #3" in link > above), as is commonly suggested. My plan is to have one "distribution" > that is our DBIC layer and then use that in a number of separate model > layers (split out by functionality). The goal is to allow separate teams > to work on different parts of the app, have separate unit tests, and > separate release schedules. And to thin out the controllers. Much more > manageable and scalable. >
I think I've added another layer but I'm not sure where you draw the line.. I have a model layer over DBIC pulling together related result classes under a single model class. Then the app? layer uses the model layer to get things done. So I'd probably have one "distribution" that is our DBIC wrapped in a model layer layer and use that in a number of apps.. 8) Each app can then be used as the single model in a Catalyst app or script or whatever.. (I think I need more names for the parts..) > > Anyone here doing something like this? As I look into this I'm coming up > with quite a few questions, of course. > I've been trying learn the steps to this little dance for a while now and still haven't put anything into production, but for what it's worth, here are some of the things I've implemented in my most recent code.. I have "Sets" in lu of ResultSets and "Models" for Results. Although in most instances a Model will actually cover the usage of multiple Results. Each Set gets the dbic schema object and knows it's resultset name. Each model has a data attribute which contains a dbic row object and "handles" any methods I don't need to override via the Moose "handles" attribute attribute!? Set->create($hash) creates the dbic object and stuffs it into a model class and returns that. Each result class that has a model class overrides it's inflate_result method which again stuffs the dbic row object into the model object so searches on the related dbic resultsets return my model objects. Each model class has a validation class based on.. Validation::Class and create & update run their input through that. If there are errors I stuff the errors into a very basic exception object and return that. This way I can return the same exception object no matter where the error comes from, eg a dbic exception.. So my app can use the Login set to create a login model which has methods to set/get email & username, check the password, set a temporary password, add to roles, and get roles by name. Beneath that is 3 or 4 DBIC result classes which the model class works with via custom methods or delegation. ok, sorry.. I'll stop there. This has turned into a brain dump and clarity has suffered badly.. I hope you got something for your trouble.. cheers, J > > This is more of a Perl question than a Catalyst one, but one question I > have is about data validation. Catalyst provides a nice defined request > structure so, for example, I have input data validation managed very > consistently (e.g. validation classes can be mapped to Catalyst actions > automatically and likewise validation errors can be added to the response > in a common way). That makes the controller code simple since when the > controller runs it knows if the data it has received is valid or not and > the controller does not worry about gathering up error messages. > > So, I'm wondering how best to do that if I provide a separate model layer > that includes data validation. For example, say I have a model for user > management which includes a method for creating new users. If I have a > model method $users->add_user( \%user_data ) I would tend to have it return > the new user object or throw an exception on failure. What probably makes > sense is using exception objects and have Catalyst catch those to render > the error in an appropriate way. Is this an approach you are using? Any > other tips on structuring the model layer that works well with both > Catalyst and non-Catalyst applications? > > Looking back, I think my question isn't that much about data validation as > is about providing a framework for model creation such that a consistent > API is provided -- making it easy to hook it into Catalyst for things like > rendering errors in a consistent way. > > Thanks for any feedback you can provide, > > -- > Bill Moseley > [email protected] > > _______________________________________________ > List: [email protected] > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: > http://www.mail-archive.com/[email protected]/ > Dev site: http://dev.catalyst.perl.org/ > >
_______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
