Hello, I'm going down the same adoption path. Coming over from Java
skipping and happy.
I'm fighting (and loosing) the urge to create a manager.py that will
basically hold business logic and interface with the models.
Additionally, I have read the unit testing documentation, and I want
to make sure I'm following a good practice to get complete test
coverage.
Finally, I don't see any reason why I shouldn't put the templates in
the app directory. But, I also don't see that recommendations to do
so.
So, I'm a bit unsure.
I'm considering this setup. Would anyone care to correct me, if I
have something not quite right?
myproject/
__init__
urls.py
settings.py
manage.py
myapp/
models.py
model_tests.py - test directly, simulating code that would go in
managers.py
managers.py - in here are classes methods that the view defs
call
managers_test.py - test directly, simulating code that would go in
views.py.
views.py
view_test.py - tests in here use Client and therefore test urls.py
and templates too. Considering having 1 default tests per def in
views.py that would be a sanity/integration test. Then, any other
specific tests that doesn't test functionallity already tested in
managers_test.py
templates/
I like this because the managers.py code organizes the business logic
away from the web controller layer, let's me doing specific testing on
it, and also decoupling it easily for hook up with GTK or QT or
something. But, it doesn't add another layer of complexity that might
not really be necessary.
I'm truly sorry if I have asked stupid questions. I will not be
offended if you ignore me. I'm going to keep reading, and I have
lot's of books on order. I'll sort it all out at some point.
cheers!!!
On Apr 5, 1:51 am, Doug Van Horn <[EMAIL PROTECTED]> wrote:
> I haven't found any 'bestpractices' for Python other than PEP-8 or
> the olderhttp://www.python.org/doc/essays/styleguide.html.
>
> Django kind of pre-defines a generalbestpractice of project layout,
> but anything outside of models, tests & fixtures, templatetags, et.
> al. is up to you (views and settings are not 'required' to be where
> they are).
>
> Anyway, it's kind of discomforting at first, coming from J2EE-land
> where everything is laid out for you in the core J2EE Patterns book.
> "Here are you DAOs, there are your Business Delegates, and over
> there's where you keep your transformers and your DTOs"...
>
> In Python/Django, you have to think a little bit more about how you
> want to lay things out and where they belong /in your project/. So
> there's not that uniform inter-corporate architecture consistency you
> find (or at least I found) when bouncing around in contract gigs for
> larger corps.
>
> If it helps, my progression went first from breaking everything up
> into small chunks in lots of files and apps (a la one class per file
> Java), to now having much bigger modules holding lots of related
> concerns (classes and functions). I think that it's more common in
> Python to do this, and it's a lot easier to remember where stuff is.
>
> for what that's worth...
>
> On Apr 3, 11:52 am, bcurtu <[EMAIL PROTECTED]> wrote:
>
> > Thanks Doug,
>
> > Well, yes, I think it's pretty easy to switch to this philosophy, even
> > it's hard to come back to java again!
>
> > I will follow my model 1, because it's generic code and it could be
> > reusable.
>
> > What about a goodpracticesreference guide... Any suggestion?
>
> > On Apr 3, 4:54 pm, Doug Van Horn <[EMAIL PROTECTED]> wrote:
>
> > > On Apr 3, 9:19 am, bcurtu <[EMAIL PROTECTED]> wrote:
>
> > > > Hi again,
>
> > > > I come form j2ee world, this is my first project in Django and usually
> > > > I feel a bit lost about general concepts.
>
> > > > My project has bit too much business code, it's a kind of datamining
> > > > tool. I have created a set of functions but I'm not sure where the
> > > > "bestpractices" say I should place them...
>
> > > > 1.- In the same folder as my app (package) is, in a different file:
> > > > app1/
> > > > __init__.py
> > > > models.py
> > > > views.py
> > > > datamining.py
>
> > > > 2.- In the same models.py or views.py file?:
> > > > app1/
> > > > __init__.py
> > > > models.py
> > > > views.py
>
> > > > 3.- In a new app (app)?
> > > > app2/
> > > > __init__.py
> > > > datamining.py
>
> > > > Thanks for your advice... and, do you know any goodpractices
> > > > reference for django?
>
> > > I came from the same world (J2EE, many years), FWIW.
>
> > > I'd choose 1 or 2. In an e-commerce app I've been working on, I have
> > > lots of Google, PayPal, and Authorize.net code that have their own
> > > modules (google_checkout.py, etc.) that reside in the app1/ folder.
> > > These functions are used by the views to check a user out.
>
> > > I also have lots of 'business logic' code around Cart -> Order ->
> > > Invoice transitions, but that code is in my models.py file, woven into
> > > Managers and Models. Again, used by the views.
>
> > > My rule of thumb is that if it's data related, it belongs in the
> > > models.py file, if it's workflow/control related, it belongs in the
> > > views.py file. Anything utilitiy-like (which kind of implies
> > > potential reuse), it belongs in it's own module.
>
> > > When you use the term datamining, it kind of tastes like Manager code
> > > (cross record stuff). If you're doing more cross-model-cross-record
> > > stuff, it's probably it's own module.
>
> > > As a former J2EE guy, it took me a while to get past the need to
> > > package everything in it's own space (1 class per file and all). I'm
> > > much more comfortable with the module approach now.
>
> > > doug.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
