On Tue, Aug 26, 2008 at 9:55 AM, Emil <[EMAIL PROTECTED]> wrote: > > In my model files I've been adding methods to manipulate tables, and > making them static methods in most cases. I've got methods for > creating new rows, querying, updating and so on. Some methods to > encapsulate operations that involve multiple tables, and some methods > are fairly generic and can be applied to various tables (using getattr > and class_mapper(x).columns, etc). > > But I keep wondering if I'm structuring all of this the right way. > Having these sorts of wrapper methods seems like a good idea, because > it encapsulates common operations and makes the controller code easier > to read. I think these things belong with the model because they're > basically just wrappers around operations that manipulate the model, > below the level of business rules or anything that would belong with > the controllers. > > I made them static methods so I could keep an operation on the > employee table associated with the Employee class and write > "Employee.copy(...)" or whatever. But it's @staticmethod because the > operation isn't on an Employee instance. Having them associated with > the relevant table seems like a better idea than just having a file of > utility functions. But then I have common operations that aren't > just on one table, and attaching them arbitrarily to one of the > classes involved isn't very satisfying. > > > So what's the best way to structure something like this? In the > relevant model files? In separate classes defined in the model > directory? Maybe an Employee class in another directory with > instances that correspond to rows or sets of rows from the Employee > table (and maybe other related tables), with methods on this new class > for the relevant operations? I can think of lots of ways I might try > to organize all of this but none of them jump out at me as being a > well-structured way of approaching all of this.
I don't know if there is any obvious best way. I use class methods to return queries or do complex calculations, but all data modification is done in the controller. If my modifications were more encapsulable than "update an object field-by-field from a form", I would use methods for those as well. I tried separating the query and ORM classes, but found that importing FooQuery was ugly, and I still had to import Foo anyway for when I needed to get a record by primary key. So I consolidated them again. But then it becomes an organizational task to group the constructor, __special_methods__, instance methods, properties, and class methods (queries). So you kind of lose any way you slice it. Another option is to just use functions. Import the module and call a query function. Especially for queries that span multiple tables, this makes sense. All my ORM classes inherit from a base class that provides a common .get method and .__repr__. That eases some of the multiple method type clutter in the classes. -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
