Python vs .Net

[Etienne Charland]

It's very easy to separate the logic from the interface. When I build
database applications, here's how I structure it. On the client machine, I
have the interface (exe project). On the server, I have a DLL file
containing the application logic, and another DLL file containing all the
code to work directly with the database. The classes inside the logic
assembly are exposed to the clients with remoting. So, yes, it can be split
into parts, and it works VERY well that way :)

different parts:
-Interface (binding the data to the interface, validating so the user don't
enter invalid data, etc)
-Logic (manages security, validations, calls Data to get/update data from
the database, etc)
-Data (executes queries to the database)
-SQL Server database (isn't exposed to clients at all, only used by Data)

and also, I can split the server work into multiple machines: I can have a
database server, and 5 servers hosting the Logic and Data parts, for
example. And then connect each client to a server. I guess it's also
possible to make clustered servers, but I haven't looked at that (no need)

"David Bolen" <db3l at fitlinxx.com> wrote in message
news:uvg12cdht.fsf at fitlinxx.com...
> "Greg Brunet" <gbrunet at nospamsempersoft.com> writes:
>
> > I've been checking out Python for a month or so after using VB for many
> > years, and having just completed a 4 month VB.NET project.  Here's a few
> > observations that I have:
>
> I suppose it's only marginally on track for a Python group, but with
> your recent VB -> VB.NET experience, I wonder if you could answer a
> question of mine, not having dug deeply into VB.NET yet ...
>
> Does VB.NET make it any easier to separate the logic design of the
> application from the GUI layout, or is it further hard-linking the
> two, such that you really end up with a bunch of controls with
> attached code rather than a coherent application design with a GUI
> layer?
>
> I know that you can manually manage your classes (keeping them
> distinct from the GUI layout, or implementing everything as COM
> objects) in VB to try to control the situation, but it's not the
> "normal" design method I've seen developers using.  From your comments
> with respect to the strong push for data linked controls, it would
> seem like VB.NET is actually going further in the direction I'm not a
> big fan of.
>
> That's one of the things I tend to prefer about something like a
> Python + wxPython solution (ob. Python reference).  I tend to design
> an application sans-GUI, and then implement the GUI as a layer above
> the business logic.  This to me improves maintainability of the core
> application, as well as making it accessible in non-GUI situations or
> in replacement GUI (e.g., web side scripting) environments without any
> significant changes - just use the core application interface without
> the GUI.  Although true, I agree that none of the current layout tools
> for Python quite approach the simplicity and robustness of the VB
> environments, which is important when you do get to the GUI layout
> stages.
>
> I've always found VB to be an extremely friendly and easy RAD, but
> that more often than not, resulted in applications where everything
> was tightly linked to the GUI layout - so much so that managing a
> structured design for the application logic itself suffered, as did
> it's long term maintainability.  I was hoping that perhaps VB.NET
> would improve things in that direction, but it sounds like it makes
> you work just as hard to keep the GUI isolated from the bulk of the
> application logic structure.
>
> --
> -- David
> --
> /-----------------------------------------------------------------------\
>  \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
>   |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
>  /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
> \-----------------------------------------------------------------------/