管理系统做的不多，但不论是什么语言开发，都能从中发现很多通用的地方，平时空闲了随时记下来的。
1、登录
登录对话框可以说是管理系统最常用的模块了，所以，有必要将其最大限度的重用。
一个典型的登录对话框不外乎下面这几点：
* 用户名输入
* 密码输入
* 角色选择
* 验证权限
* 信息反馈
因此，用类封装好这几个属性或者方法即可。
2、基本表增、删、改
很多时候，系统对于基本表的增、删、改是必不可少的，这里的基本表是指对一个数据库实体进行的操作。该模块可以建立与数据库表和字段相关联的属性及操作，并达到高弹性的可定制性。比如：可以使用一个数组或链表来存储与数据库字段的映射，并通过相关方法使数据同步操作（在这里不同于DELPHI的数据库组件的思想，DELPHI的数据库操作组件将数据和视图及逻辑写到了一起，这样就导致了它相对较差的可定制性。这里提到的模块仅仅将数据和逻辑相分离，并且与显示无关，以减少数据封装粒度）
3、数据库操作
目前管理系统似乎已经成为了数据库外壳的别称了，的确，管理系统的核心还是在数据上。因此，系统对数据库操作的方便性、可扩充性、稳定性和性能都是关系到整个管理系统优劣的关键。
我们已经拥有了通用的数据库操作语言SQL，但是随着系统和应用的日趋庞大，仅仅靠与程序语言结合甚弱的SQL已经不能满足需要，所以在这一层面，有必要设计一个健壮的可操作层，来适应庞大的数据量及频繁的数据操作。
对于数据操作层设计的几点注意如下：
* 数据库标准化和兼容性。目前数据库系统虽说不是那种群雄逐鹿的局面，但他们都其各自拥有不同的操作约定和数据定义，因此，统一的操作标准和兼容性是数据层存在的前提。
* 连接性能。连接池的出现让我们摆脱了每次访问数据库时都需要重新建立连接的郁闷局面，在数据层设计的时候同样不要忘记建立数据连接缓存，因为作为一个独立操作的模块，数据层会被频繁的访问，很多时候为了节省资源，我们甚至需要在使用它的时候创建，之后销毁。因此，即便是很高效的连接池也会因为频繁的创建/释放而最终罢工。
这是在经过两种不同语言的实现中发现的问题。起初，我用delphi写了一个基于ADO连接的数据层操作类，并在每次创建该类实例的时候创建数据库连接，并在销毁对象的时候关闭连接。这个类我一直用到现在，没出现问题（这次DELPHI的高效让我郁闷了一阵），可是当我把这个类移植到.NET下的时候，问题来了。.NET运行环境是托管于虚拟机的，所以在操作连接池的时候并没有WIN32程序那样的效率，况且在手动关闭连接的时候（由于.NET环境下对象的销毁是没有预期的，因此我设计了一个强制关闭连接的机制），.NET并不会将连接放入缓冲池（或者是来不及，我的一次操作有的会以不同方式访问N次数据库），所以很快，系统便报出了连接池已满的异常。
为了解决此问题，我在Web方式下的数据层中使用了Session变量来保存数据库连接，只有在一定的条件下才会创建数据库连接，这样就大大提高了系统的执行效率。
* 使用合适的操作封装粒度。随着数据操作越来越复杂，多表连接查询或操作已经是目前系统的主力军，因此，应该将这一类操作写成存储过程，让数据库系统替我们封装一些复杂的操作。但是也应该注意，存储过程封装的操作尽量不要带有系统逻辑特有的信息，以达到更好的复用性和灵活性。比如：将用户信息的多表查询封装为存储过程，而尽量不要将保存一个产品时同时修改用户表的相关数据写成存储过程。当然，这个封装粒度的掌握要权衡系统的复杂度及灵活性。
