创建多层客户端/服务器应用程序

问题描述：

大家好。我在这里搜索过这些档案，看起来似乎已经出现了与此类似的问题，但是我希望我可以选择你的Pythonic大脑。

这里是我需要做的广泛概述：跨平台，客户端 -

侧面GUI应用程序交互使用由数据库支持的服务器。我会给b $ b也喜欢为小部分设置一个网页界面的可能性

的应用程序。对于管理人员（以及培训，绩效评估等）和工资单来说，这将是一个相当复杂的系统，我将会花费大约一年或更长的时间来支付b $ b。写吧。

这些都没有写 - 实际上，它甚至还没有达到

规格，我是只是试着学习最好的方法*之前*我

达到规格。我想在编写任何代码之前尽可能完整地计划这个应用程序

，我想这样做正确

Way（TM），因此我有（希望如此））说服我的经理（和客户）

Python是要走的路。我有几年的经验，但它主要是网络应用程序（我完全厌倦了

制作，感谢PHP）和简单CLI程序。不确定是否有任何信息有用，但我很累，所以请耐心等待。

应用程序肯定需要至少三层：客户端，服务器，

和DB。我希望尽可能少的客户端逻辑（如果不是
none），因为数据库中会有敏感数据。我也不能直接连接到数据库，因为它只需要在本地主机上接受

连接。客户可能会在50-100台机器上安装

，并且将被数百人使用（是的，

他们正在共享机器 - 用户将是计算机实验室顾问/

服务器运营商/服务台员工等及其主管），所以

身份验证（使用LDAP）和授权（使用组我将

define）将非常重要。同样重要的是客户端的自动更新，我想通过比较版本

数字，然后下载档案（鸡蛋，可能？？）最新的

（已编译？字节 - ？）代码。

我可能会在wxPython中创建GUI，因为这似乎是最好的

灵活且很好的跨平台选择 - 但我愿意接受建议。
建议。不过不太担心那个。

对于数据库，我会使用Postgres，因为我喜欢Postgres。

可能不会让步在那个，除非任何人有任何好的

理由。我也想使用SQLAlchemy（因为它太棒了），

但这不是必需的（我可以编写SQL，但是...... SQLAlchemy是

很好。）我想使用ORM主要是因为它可以方便地为（非常简单的）网络界面重新使用
代码重用，以及其他分支

工具下线。

所以，我真正的问题（对所有的说明感到抱歉）是这样的：如何进行网络连接？b $ b我真的想让客户端发送一个

简单请求到取这个（或这些）

对象的行。 ;或者更新此对象中的此值，然后让服务器确定是否允许用户实际执行此操作，然后将

更改为数据库。

我的第一个想法是XML-RPC，因为我以前用过它，它是如此美好和干净 - 但是然后我就不能发送物品，这真的很重要。

然后我看着Pyro，这看起来很棒，但我是混淆了如何

（如果可能的话）我会将它与DB一起使用。我是否必须弄清楚客户端要发送哪些SQL查询才能获得正确的对象？
那将是b / b $ b类杀死逻辑的分离。它是否适用于

SQLAlchemy（或任何ORM）？

我看了SOAP。这让我觉得不洁净。我看了一些CORBA，

，此时我的眼睛茫然（可能不是CORBA'的错，我会

以后再看一遍）。

我检查了Twisted，但是它有很多部分，

我不确定从哪里开始。

我不排除编写我自己的简单协议，但似乎

我将重新发明一个已经被重新发明的*无数

次。

所以，所有这一切 - 关于如何进行网络建设的任何建议？并在

自动更新？就此而言，对我提到的任何事情都有任何建议

（或者没有？）请随时让我澄清任何事情，或者告诉

me如果我是个白痴的话。

谢谢，

杰夫

Hello everyone. I''ve searched through the archives here, and it seems
that questions similar to this one have come up in the past, but I was
hoping that I could pick your Pythonic brains a bit.

Here''s a broad overview of what I need to do: cross-platform, client-
side GUI apps that interact with a server backed by a database. I''d
also like the possibility of having a web interface for small portions
of the app. It will be a fairly complex system for managing personnel
(and training, performance reviews, etc.) and payroll, and I will
probably have about a year or more to write it.

None of this is written yet--actually, it''s not even to the point of
specs yet, I''m just trying to learn the best way to do this *before* I
get to the specs. I want to plan this application out as thoroughly
as possible before writing any code, and I want to do it The Right
Way(TM), hence I have (hopefully) convinced my manager (and clients)
that Python is the way to go. I have a couple years of experience in
Python, but it''s mostly been web apps (which I am thoroughly sick of
making, thanks to PHP) and simple CLI programs. Not sure if any of
that information helps, but I''m tired, so please bear with me.

The application definitely needs at least three tiers: client, server,
and DB. I want as little logic in the client as possible (if not
none), as there will be sensitive data in the DB. I also can''t have
the clients connect to the DB directly, as it will need to only accept
connections on the local host. The client will probably be installed
on 50-100 machines, and will be used by several hundred people (yes,
they''re sharing machines--the users will be computer lab consultants/
server operators/helpdesk employees, etc. and their supervisors), so
authentication (using LDAP) and authorization (using groups I will
define) will be very important. Also important will be automatic
updates of the client, which I figure I''ll do by comparing version
numbers, then downloading an archive (egg, maybe?) of the latest
(compiled? byte-?) code.

I will probably make the GUI in wxPython, as that seems to be most
flexible and nicely cross-platform choice--but I am open to
suggestions. Not too worried about that one, though.

For the database, I''ll use Postgres, because I love Postgres.
Probably not going to budge on that one unless anyone has any good
reasons to. I''d also like to use SQLAlchemy (because it is so nice),
but this is not a requirement (I can write SQL, but... SQLAlchemy is
so nice.) I''d like to use an ORM mainly because it would facilitate
code reuse for the (very simple) web interface, and other offshoot
tools down the line.

So, my real question (sorry for the all the exposition) is this: how
to do the networking? I''d really like to have the client send a
simple request to the server along the lines of "fetch this (or these)
object(s)", or "update this value in this object", then let the server
decide if the user actually is allowed to do so, and then make the
change in the database.

My first thought was XML-RPC, because I''ve used it before, and it is
so nice and clean--but then I can''t send objects, which is really
rather crucial.

Then I looked at Pyro, which seems awesome, but I''m confused as to how
(if possible) I would use it with a DB. Would I have to figure out on
the client what SQL query to send to get the right objects? That would
kind of kill the separation of logic. And would it work at all with
SQLAlchemy (or any ORM for that matter)?

I looked at SOAP. It made me feel unclean. I looked at some CORBA,
at which point my eyes glazed over (possibly not CORBA''s fault, I will
look at it again later).

I checked out Twisted, but there are so vastly many parts to it, that
I''m not sure where to even start.

I''m not ruling out writing my own simple protocol, but it seems like
I''d be reinventing a wheel that''s already been reinvented countless
times.

So, all that said--any advice on how to do the networking? And on the
auto-update? For that matter, any advice on anything I''ve mentioned
(or haven''t?) Please feel free to ask me to clarify anything, or tell
me if I''m being an idiot about anything.

Thanks,
Jeff

答

Jeff< je ***** @ gmail.comwrites：

Jeff <je*****@gmail.comwrites:

这里概括了我需要什么do：跨平台，客户端 -

与数据库支持的服务器交互的GUI应用程序。我会给b $ b也喜欢为小部分设置一个网页界面的可能性

的应用程序。 ...对我提到过的任何建议

（或者没有？）

Here''s a broad overview of what I need to do: cross-platform, client-
side GUI apps that interact with a server backed by a database. I''d
also like the possibility of having a web interface for small portions
of the app. ... any advice on anything I''ve mentioned
(or haven''t?)

为什么不做整个应用程序作为一个网络应用程序，完全打包客户

方并只使用浏览器？这将有助于您的部署问题

很多，并且使用https将有助于安全性，因为它看起来像

应用程序将传输敏感数据。由于你只是在编写服务器，它还会简化你的网络问题。

看看Chris Mellon和我之间的争论几个星期前关于

网络应用程序与客户端gui应用程序。是的，你可以从一个客户端应用程序获得一个

的响应水平，这是一个不容易通过网络

应用程序完成的。然而，我个人使用的客户端gui商业应用程序相对较少，看起来似乎比以明显的方式使用

网络应用程序所做的相同。

我肯定会将应用程序原型化为一个网络应用程序，然后想想

写一个客户端gui只有在显然可用性确实是真的

从中受益。即使如此，服务器仍然看起来像一个web

服务器，将xml请求转换为数据库操作并用xml响应

。

Why not do the entire app as a web app, completely bagging the client
side and just using a browser? It will help your deployment problems
a lot, and using https will help with security since it looks like the
app will be transmitting sensitive data. It also will simplify your
networking questions a lot since you''re just writing a server.

See the big debate between Chris Mellon and me a few weeks ago about
web apps vs client gui apps. Yes you can get a level of
responsiveness from a client app that can''t easily be done with a web
app. However, relatively few client gui business apps that I''ve
personally used really seem better than the equivalent things done as
web apps in the obvious way.

I would certainly prototype the app as a web app, and then think about
writing a client gui only if it was clear that usability would really
benefit from it. Even still, the server would still look like a web
server, translating xml requests into database actions and responding
with xml.

我想在编写任何代码之前尽可能完整地计划这个应用程序

，

I want to plan this application out as thoroughly
as possible before writing any code,

有一所学校这个想法比你应该做的更有计划性。（/ b）想想一次越野汽车之旅。找出你要采取的一般

路线，然后进入车内去，做出低级别的b
决定，而不是试图计划每一个汽油和

休息和餐馆在您离开前停止。

There is a school of thought (sometimes associated with "extreme
programming") that this is more planning than you should really do.
Think of a cross-country automobile trip. Figure out the general
route you want to take, then get in the car and go, making low-level
decisions as you get to them, rather than trying to plan every gas and
rest and restaurant stop before you leave.

Paul Rubinaécrit：

Paul Rubin a écrit :

Jeff< je ***** @ gmail.comwrites：

Jeff <je*****@gmail.comwrites:

>这里概述了我需要做的事情：跨平台，客户端 -
侧GUI应用程序，与数据库支持的服务器交互。我也希望能够为应用程序的一小部分提供Web界面。 ......对于我提到过的任何建议
（或者没有？）

>Here''s a broad overview of what I need to do: cross-platform, client-
side GUI apps that interact with a server backed by a database. I''d
also like the possibility of having a web interface for small portions
of the app. ... any advice on anything I''ve mentioned
(or haven''t?)

为什么不将整个应用程序作为Web应用程序，完全打包客户

方并只使用浏览器？这将有助于您的部署问题

很多，并且使用https将有助于安全性，因为它看起来像

应用程序将传输敏感数据。由于您只是在编写服务器，它还会简化您的

网络问题。

（snip）

(snip)

>

我当然会将应用程序原型化为网络应用程序，然后再考虑

只写一个客户端gui如果很明显可用性真的会从中获益b $ b。即使如此，服务器仍然看起来像一个web

服务器，将xml请求转换为数据库操作并用xml响应

。

>
I would certainly prototype the app as a web app, and then think about
writing a client gui only if it was clear that usability would really
benefit from it. Even still, the server would still look like a web
server, translating xml requests into database actions and responding
with xml.

我个人赞成json，它更轻巧，非常适合

结构化数据，并得到广泛支持。

否则，客户端已实现（富客户端或网络 -

另一种可能的解决方案是基于Mozilla平台，

但我没有工作经验，所以我不知道这是不是很好

想法...），我会再次提出建议，仔细看看http

协议。在Python中编写基于http的服务器

应用程序并不缺乏支持（鉴于上下文，我强烈建议使用Pylons）。

I''d personnaly favor json, which is much more lightweight, perfect for
structured data, and widely supported.

Else, and however the client is implemented (rich client or web -
another possible solution being something based on the Mozilla platform,
but I have no working experience with it so I can''t tell if it''s a good
idea...), I''d second the suggestion to have a closer look at the http
protocol. There''s no shortage of support for writing http-based server
applications in Python (given the context, I''d strongly suggest Pylons).

>我想在编写任何代码之前尽可能完整地计划这个应用程序，

>I want to plan this application out as thoroughly
as possible before writing any code,

有一种思想流派（有时与极端的b
编程相关联），这比你应该做的更有规划。

想象一个越野汽车旅行。找出你要采取的一般

路线，然后进入车内去，做出低级别的b
决定，而不是试图计划每一个汽油和

休息和餐馆在您离开前停止。

无论如何，除非你是具有数十年工作经验的天才，否则你可以打赌你会犯下很多错误在你的计划中，在实施可能过度设计的设计时，你会发现错误。我是

当然*不*在这里宣传牛仔编码方法，并且

初步工作对于任何非平凡的事情都是强制性的，但是

请注意你真正需要担心的事情。 AFAICT，你到目前为止好像b $ b似乎在正确的轨道上（考虑到一些已知的要求，考虑可能的b $ b架构），但AMHE，

BigDesignUpFront只是不起作用，所以不要过度计划。

我的2美分......

Anyway, unless you''re a genius with decades of working experience, you
can bet you''ll make lots of mistakes in your "planning", mistakes that
you''ll discover when implementing a probably over-engineered design. I''m
of course *not* advertising a cowboy-coding approach here, and
preliminary work is certainly mandatory for anything non-trivial, but
take care about what you really have to worry about here. AFAICT, you
seem to be on the right track so far (thinking about the possible
architectures given some already known requirements), but AMHE,
BigDesignUpFront just doesn''t work, so don''t overplan.

My 2 cents...

也许Spring Python可以帮助你（ http://springpython.python-

hosting.com）。它重用了像Pyro这样的技术用于远程处理，提供了数据库模板，有一个可插拔的安全组件，一个AOP解决方案

，如果需要，还有一个IoC容器，还有一对web-app

演示使用CherryPy。当然，你可以使用你想要的任何网络堆栈。我刚刚选择了CherryPy进行演示。

Spring Python的每个组件都是可选的，你可以通过IoC容器或者以编程方式使用它来获得
。这可能会帮助你

利用企业应用程序的开发。

BTW，我计划实现一个wxPython前端示例应用程序。我只是

还没有完成它。

祝你好运！

Perhaps Spring Python can help you out (http://springpython.python-
hosting.com). It reuses technologies like Pyro for remoting, offers
database templates, has a plugable security component, an AOP solution
should the need arise, an IoC container, and has a couple of web-app
demos using CherryPy. Of course, you can use whatever web stack you
want. I just picked CherryPy to demo things.

Each component of Spring Python is optional, and you can use it
through the IoC container, or programatically. This might help you
leverage development of an enterprise app.

BTW, I have plans to implement a wxPython front end sample app. I just
haven''t done it yet.

Good luck!

创建多层客户端/服务器应用程序

相关推荐