Re: Database access pattern

[Malthe Borch]

http://docs.sqlalchemy.org/en/latest/orm/tutorial.html

That's assuming you're using SQL.

\malthe

On 6 June 2012 09:50, tanshu <tan...@gmail.com> wrote:
> Hi,
> I am sorry if this has been asked before, but I couldn't find the answer
> anywhere.  I am relatively new to python / pyramid and have developed a few
> test programs.  I come from a C# background and could not figure out what
> the best pattern is to lay out database access.
>
> In C# etc, you create separate dal classes and go with n-tier architecture,
> should I just the validation, save, update in the controller in pyramid or
> create separate classes.  Any help will be gratefully appreciated.
>
> Thanks in advance. :)
>
> tanshu
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/pylons-discuss/-/5-_3loZtH5wJ.
> To post to this group, send email to pylons-...@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-discus...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-discuss?hl=en.

[tanshu]

Thanks malthe for.

I read that documentation and am using the same, but my question was about where these statements should be put?  In the view, a separate class (eg. DAL pattern), or in the Model? 

Coming from a n-tier application developer, I am unable to figure out how to improve maintainability of the application and reduce duplication.  I was hoping that someone could point me to a guide of the way to do these things in pyramid or just share with me how they do things. :)

In the meanwhile, I was looking at the reddit source, and I think that they do it in the models.  In your opinion is it the right way? Any help would be greatly appreciated.

Thanks for your reply.  
tanshu

On Wednesday, June 6, 2012 3:21:11 PM UTC+5:30, malthe wrote:

http://docs.sqlalchemy.org/en/latest/orm/tutorial.html

That's assuming you're using SQL.

\malthe

On 6 June 2012 09:50, tanshu <tan...@gmail.com> wrote:
> Hi,
> I am sorry if this has been asked before, but I couldn't find the answer
> anywhere.  I am relatively new to python / pyramid and have developed a few
> test programs.  I come from a C# background and could not figure out what
> the best pattern is to lay out database access.
>
> In C# etc, you create separate dal classes and go with n-tier architecture,
> should I just the validation, save, update in the controller in pyramid or
> create separate classes.  Any help will be gratefully appreciated.
>
> Thanks in advance. :)
>
> tanshu
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/pylons-discuss/-/5-_3loZtH5wJ.

> To post to this group, send email to pylons-discuss@googlegroups.com.

> To unsubscribe from this group, send email to

> pylons-discuss+unsubscribe@googlegroups.com.

[Malthe Borch]

On 6 June 2012 11:59, tanshu <tan...@gmail.com> wrote:
> I read that documentation and am using the same, but my question was about
> where these statements should be put?  In the view, a separate class (eg.
> DAL pattern), or in the Model?

I think you'll want to everything in your view code, unless it's very
generic (i.e. "helper" code).

> Coming from a n-tier application developer, I am unable to figure out how to
> improve maintainability of the application and reduce duplication.  I was
> hoping that someone could point me to a guide of the way to do these things
> in pyramid or just share with me how they do things. :)

You'll probably find that reusability in Python web programming is a
difficult balance. The Python language is very easy, and you can write
code in a few lines that does a lot. This sometimes means that it's
not worth it to try and generalize everything.

I think the goal is to avoid bugs. If you've got code that's "risky"
or "difficult", then at the very least try not to write it twice.

\malthe

[tanshu]

Got it.  I was also beginning to think in a similar way, but because of the baggage of the old, was not sure.

Will put the Business Validation Code in helper functions and the save code in the views. 

Thanks for the help.

tanshu

[Vlad K.]

On 06/06/2012 09:50 AM, tanshu wrote:
> Hi,
> I am sorry if this has been asked before, but I couldn't find the
> answer anywhere. I am relatively new to python / pyramid and have
> developed a few test programs. I come from a C# background and could
> not figure out what the best pattern is to lay out database access.
>
> In C# etc, you create separate dal classes and go with n-tier
> architecture, should I just the validation, save, update in the
> controller in pyramid or create separate classes. Any help will
> be gratefully appreciated.
>

My preference lately is to move all business and data logic to model
methods and use views only to do views: ACL and context setup for
template and response, a glue between involved models, templates,
request data and response construction.



--

.oO V Oo.

[Mike Orr]

I generally put business logic in the model, but I may have a
different notion of business logic than Tanshu does. To me, business
logic is any calculations that are specific to the model but are
*independent* of the UI and HTML. So form validators belong in the
view, not the model. At most there might be a *generic* .__html__()
method on a model object to return its standard HTML representation.
But normally I put all HTML-related stuff in the templates or view.

If the business logic relates to a specific DB record, you can use an
ordinary method on the ORM class for it. But usually it relates to the
table; i.e., it returns a certain number of records. In that case it's
a class method on the ORM class (using @classmethod). Alternatively,
you can have a function in the model.

Some examples are in the Models chapter of the "Pyramid for Pylons
Users" guide in the Pyramid Cookbook.
http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/pylons/models.html


--
Mike Orr <slugg...@gmail.com>

[Vlad K.]

On 06/06/2012 09:18 PM, Mike Orr wrote:
> I generally put business logic in the model, but I may have a
> different notion of business logic than Tanshu does. To me, business
> logic is any calculations that are specific to the model but are
> *independent* of the UI and HTML. So form validators belong in the
> view, not the model. At most there might be a *generic* .__html__()
> method on a model object to return its standard HTML representation.
> But normally I put all HTML-related stuff in the templates or view.
>
> If the business logic relates to a specific DB record, you can use an
> ordinary method on the ORM class for it. But usually it relates to the
> table; i.e., it returns a certain number of records. In that case it's
> a class method on the ORM class (using @classmethod). Alternatively,
> you can have a function in the model.
>
> Some examples are in the Models chapter of the "Pyramid for Pylons
> Users" guide in the Pyramid Cookbook.
> http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/pylons/models.html
>

I'd argue that model data validation, which may be another way to call
form validation, belongs to the model. For that I use colander which is
then agnostic of the input method (form, XML, JSON API, ...). If the
validator raises exceptions, then the view can handle them
appropriately: construct warnings, mark invalid fields, etc... which
then clearly belongs to the view and template. The same validators are
then available to command line scripts that reuse the models, cron
tasks, ..., and it is even nicely unit-testable.



--

.oO V Oo.

[Mike Orr]

On Wed, Jun 6, 2012 at 3:06 PM, Vlad K. <vl...@haronmedia.com> wrote:
> On 06/06/2012 09:18 PM, Mike Orr wrote:
>>
>> I generally put business logic in the model, but I may have a
>> different notion of business logic than Tanshu does. To me, business
>> logic is any calculations that are specific to the model but are
>> *independent* of the UI and HTML.
>

> I'd argue that model data validation, which may be another way to call form
> validation, belongs to the model. For that I use colander which is then
> agnostic of the input method (form, XML, JSON API, ...). If the validator
> raises exceptions, then the view can handle them appropriately: construct
> warnings, mark invalid fields, etc... which then clearly belongs to the view
> and template. The same validators are then available to command line scripts
> that reuse the models, cron tasks, ..., and it is even nicely unit-testable.

I have not used Colander. It may be more viable for the model than
FormEncode is.
I just find that FormEncode gets too close to the UI (the HTML
representation of booleans, the way nested variables are flattened
into <input> IDs, etc) to be part of the model. I keep my validators
in a separate module distinct from either the model or views.

--
Mike Orr <slugg...@gmail.com>

[tanshu]

I have never used Colander either and will try it for the validations.  I have a LOT of db related validations so as Mike suggested I am trying to put them in the @classmethod.

Thanks for all the great replies.  It just takes a little bit getting used to not having multiple assemblies, but love the flexibility the framework allows.

Tanshu

On Thursday, June 7, 2012 11:12:30 PM UTC+5:30, Mike Orr wrote: