PeakDatabaseApplications

UserPreferences

1 Introduction

PEAK is an excellent platform for building Python database applications. Using a combination of several PEAK packages one can build powerful and flexible database applications quickly and easily.

2 First Steps: Binding and Naming

We should first discuss briefly the PEAK packages we'll be working with, starting with peak.binding and peak.naming.

Peak's binding package provides powerful utilities for building component-based applications. This typically means that you create a top-level application class of some sort which instantiates the various component objects needed to accomplish the task at hand. With peak.binding these "component objects" will be able to find each other, most often by defining properties that "bind to" other objects in the hierarchy. Here's a quick example:

    1 from peak.api import binding, storage
    2 
    3 class Worker(binding.Component):
    4     db = binding.Obtain(storage.ISQLConnection)
    5     def doWork(self):
    6         for row in self.db('select name, description from aTable'):
    7             print row.name, row.description
    8 
    9 class Application(binding.Component):
   10     db     = binding.Obtain('sqlite:test.db', offerAs=[storage.ISQLConnection])
   11     worker = binding.Make(Worker)
   12 
   13     def run(self):
   14         storage.beginTransaction(self)
   15         self.worker.doWork()
   16         storage.commitTransaction(self)
   17 
   18 if __name__ == '__main__':
   19     from peak.api import config
   20     root = config.makeRoot()
   21     app = Application(root)
   22     app.run()

As subclasses of binding.Component, the Application and Worker classes are capable of taking part in a component hierarchy. Such a hierarchy needs a "root" object at its base -- we use config.makeRoot() to create a component root object on line 20. On line 21 we instantiate an Application object, specifying that root will be its parent. When creating binding.Component-based objects by hand like this, one must always pass a parent object as the first parameter. When using bindings within a class definition (as done on lines 4, 10, and 11) the parent object for the new component will be supplied automatically, if needed.

This small example is already a working database application. It opens a connection to a SQLite database file, runs a query against a table, and prints the results. It also demonstrates one of the most useful aspects of the binding package: the ability to create an object once and make use of it in another part of the application. In database applications you usually want a single connection to a database server which will be shared throughout the application. Without binding one would have to either create the connection object and pass it to every new object that needed it, or provide it to the rest of the application using a singleton mechanism of some kind.

The former technique is highly error prone and forces the application to be "tightly coupled" -- that is, objects need to know quite a bit about each other and are usually highly dependent on each other's interfaces and structure. Changing one object in a tightly coupled application often requires changes to a number of other objects, and in large applications these inter-dependencies are not always known by every programmer or are easily missed. Tightly coupled software tends to be extremely brittle as a result. 深圳机票胶袋,深圳胶袋胶带,深圳胶带机票光端机钢管风机锅炉变频器润滑油离合器狐臭糖尿病电容灰指甲近视眼脱毛净水器蜂蜜紧固件制服健身器材太阳能婚纱摄影LED酒店水表锅炉打包机痔疮发电机深圳装饰切割机深圳印刷深圳条码激光设备照排机餐具私家侦探六合彩脱发治疗网深圳机票快递|速递公司网络电话水晶融资电脑维修出国开关电源模具纳米污水处理物业管理VOIP网关IP电话软交换GK网络电话治疗脱发治疗脱头发网络电话卡VOIPVOIP网络电话移民幕墙五金脂溢性脱发脱发特效药生发产品脱发产品治疗白发毛发移植头发移植视频会议汽车租赁贴纸饮水机不锈钢自体毛发移植皮肤病伟哥高血压交换机注册香港公司深圳机票六合彩视频点播速递公司国际货运报警器茶叶补品增高壮阳青春痘化妆品治脚气鱼鳞病白癜风实木地板签证考勤机深圳酒店科迅公用电话通用计费系统语音网关ip超市话吧ip公话超市voip在线交易中心集团电话保健品板蓝根防盗门监控包装机电缆门禁瓷砖电机耳机卫星电视监视器变压器对讲机传感器电子元器件刀具地毯竹炭 The singleton approach can help quite a bit by ensuring that only one instance of a certain type of object exists and that it can be found relatively easily. In Python this is often achieved through a separate module and module-level variables. The great drawback of a singleton, however, is that there's only one of it. Classes that use singletons are less reusable, because you can't create instances that use different values for a singleton. (Because then it wouldn't be a singleton!) So, classes that use singletons are still tightly coupled.

What is typically needed in larger applications is a flexible way to create, lookup, and use "singleton-like" objects. PEAK calls such objects "service components", and part of what PEAK's binding package provides is easy access to such components, using looser forms of coupling such as:

• lookup by interface (line 4)
• lookup by naming service (line 10)
• "publishing" components by interface (also line 10)
• automatic creation of needed components (line 11)

When a class embeds all its dependencies in "attribute bindings" like these, the class can easily be reused via subclassing or by simply setting attributes on instances.

... to be continued ...