求教一些小型软件开发的一些经验问题
0
悬赏园豆：20
[已解决问题]
解决于 2015-02-26 22:29
在小公司工作一年了，遇到些问题一直憋在心里，请教下园子里的朋友#-#
需求背景
我在“重写”关于“XXX调查”这么个软件，主要就是对调查表格数据的CRUD。使用WPF开发的桌面软件。
调查表有的就是像Excel那样的行列式表（table），有的就像——户口本那种（汗。。）——就是表中有表的。客户给的调查表都是中文名称的，名字很长而且很难翻译为对应的英文。客户给的表名称大概就是“表1 XXXXXXX调查记录表、省级XXXXXXX资源统计表”这样的。也就是每个表都有“编号”，也没啥实际含义，算是个唯一标识的作用。
- 第一个问题是关于模型类命名和数据库设计及命名的：
A 先是数据库设计的问题
软件用的Access数据库，为了部署简单（这个很重要，而且客户习惯Office）。现在库里表名和字段都是中文——按照客户的Word表格里的名称。客户可以直接自己“查看”Access的文件。
面临的问题就是后面数据汇总后可能很大——就需要别的数据库了，真担心中文名称就是挖坑。。。字段名的英文还好说，其实我不知道怎么办的就是表名——以及对应表的实体类的名字。
B 代码里对应的Model/ViewModel属性名称是英文，就是对类名称的确很困惑。。
因为一个类“基本”就是对应一张调查表，因为表名实在是找不到有意义的名字我就直接是Form1、Form2。。这样的，其中的数字就是对应的表的序号。自己感觉挺扯蛋。中文名首字母也行不通——表名基本在10-30个汉字。也没有什么有“官方”性质的（就是国家规范）代码。。
不知道朋友们遇到这种情况怎么处理表名和类名呢？？？
2 数据库表设计问题
大多数调查表的样子如下：
|+++++++++++++++++++++++++++++++++++++++++++++|
省______ 调查人_______ 时间_______
街道编号____ 街道名称 _______ 区域面积________ 负责单位_______
|+++++++++++++++++++++++++++++++++++++++++++++|
序号 | 列1 | 列2 | 列3 | 列4 | 列5 | 列6 | 列7 | 列... | 列n |
————————————————————————————————————|
第一行
————————————————————————————————————|
第二行...
————————————————————————————————————|
基本都有“表头”，我归纳了4种情况：
A 没表头。一张表对应一个对象。比如“表1”我就对应一个Form1对象，对应数据库表Form1的一行。
B 有表头，但表头信息是诸如“省，填表人，时间”这样的。我感觉这些字段还是属于其下“每一行”的列，只是放上面因为很多行都是一样的。这种我是一行一个对象。比如“表2”，对应数据库Table2的一行是对象Table2Record。
C 有表头，但表头字段除了“省，填表人，时间”这些，还有其它的字段。比如表头是“街道编号”，然后几个字段是关于此街道的信息。这种情况下，表头字段有可能很多，也有可能很少——但总感觉不是属于下面的行。而是一个独立的信息。甚至可以说表头是一个信息，比如街道信息，而下面的行是属于此街道的调查记录。
D 表中有表。很坚定的就设计为两张表（主从表）了。
对于C情况，有些表头的信息虽然有点独立——但是字段很少，存储在单独的表感觉好别扭。原来的库设计的是不区分表头——也就是不论表头是什么字段，数据库是一张表：“调查表表头+调查表一行记录=数据库一行”。现在打算分开存，但不知道有什么数据库理论上的根据，像上面这种表格该如何设计其表结构？
而且本身表名称就很让人恶心了，再多些本身就不是用户给的表的数据库表，就更不知道该怎么叫了。。。#-#
3 关于WPF MVVM模式下Model和ViewModel的关系？
软件使用WPF做的。Model就直接是表的一行的映射。
ViewModel我现在几乎就是对Model的简单封装——调查表字段很多，而且一个界面一个ViewModel，一个Model，一个表这样的对应关系。
ViewModel的额外作用有“典型的”：
A 用户选择一个字段值后其它若干个字段（类似所属类别这样的）都自动确定。
B提供ComboBox的选项列表——列表也会因为其它字段的当前值动态变化，如省市县那种 。
C．。。。记不起来了
自己感觉把MVVM用的很扯蛋，但项目的确就是这种简单的CRUD，类之间的对应关系本身就单一，没有什么角色权限或者复杂的业务逻辑。。。。
现在最头疼的就是ViewModel封装Model的属性——每个都封装，工作量大而且 从View的XAML绑定来看也不是所有属性都需要ViewModel那样的功能——上面的A，B。
不封装一下也很别扭，觉着一部分绑在Model上，一部分绑在ViewModel上，好奇葩。。
现在软件几乎就是界面决定了ViewModel和Model——就是在View的后台代码里给DataContext赋值ViewModel，但看MVVM的概念它们应该是分开的？？？
大家帮看下我的类该怎么分呢？Model可以直接绑到View上吗——就是在查询返回Model对象集合的时候直接帮给View（DataGrid）而不是ViewModel，因为数据库查询返回的是Model对象。。。
4 数据访问
数据访问层只是一些简单的CRUD，不需要并发。。以前写的都是静态类/方法：比如Form1DAO.Insert(form1 record)这样的。后来看了些博客，不推荐数据访问对象是静态的。
我有点疑问就是，当对象只有方法的时候，静态类和实例的对象在使用上会有区别吗？
或者类不是静态的，但CRUD的方法还是静态的，这样可以吗？
问题补充：
调查表：
表1 目的物种所处植物群落概况表
表2-1 目的物种记录表
表2-2 目的物种记录表
表3 县级（自然保护区）野生资源数量统计表
表4 省级野生资源数量统计表
表5 目的物种人工培植状况调查表
表6 目的物种人工培植状况省级汇总表
表7 野生植物人工培植单位调查统计表
最佳答案
0
这些做法确实不太利于维护，如果是一般的小项目，谁在乎呢？
1、对于命名，最好还是用英文的，一个是习惯，一个是兼容。
2、数据表建议对业务进行一部分抽象，不要完全直接复制表单字段。
3、Model跟着表走，ViewModel跟着业务走，因为你的表和业务基本一对一，所以就感觉比较像了。
4、关于静态动态，你怎么习惯怎么用吧，影响不大。对于大一点的项目，这就是设计问题了。
收获园豆：7
谢谢，我的任务是修改旧软件，使用WPF，并且让代码更清晰些（汗...）我再补充下：
1. 那我的数据库表和类名都使用 Form1，Form22这样的，实际表名是“表1 目的物种所处植物群落概况表”和“2-2 目的物种记录表” ， 这里的数字是表名 对应的序号，我需要改成Form1st ,form2nd 这样来加强 “序号”的意思不？ 有的表我叫Form有的叫Table，前者是没表头的，后者是 “有表头+Grid” 那种的。*-*
2 比如“表33” 的表头里有 “填表人，时间，街道编号，街道名称，区域面积”这样的字段，而表内容Grid的列是对应调查表内容的若干字段。 抽象是否意味着我把表头的 “街道信息” 单独一张表，而 Grid部分再对应一张表？
吐槽下， 做程序一年多了觉着小项目不锻炼人，业务还很单一，冷门。客户都说不清很多需求。。。目前最大的挑战就是数据库的设计和类名了，起个名字好难的说、、
@everhad:
对于1，你的该法没什么用哇。修改为类似一下的形式可能会更好，当然名字比较长，可以适当的用简写： PurposeSpecie_PlantCommunities(目的物种_植物群落) PurposeSpecie（目的物种）
对于2、需要根据关系来进行表设计，这是关系型数据库的特色哇。
谢谢，上面我补充列出了 7张表的名字。
因为自己没法全部翻译，为了统一就用了FormN这样的。 具体对应的时候得直接去文档。。。看类名是的确无法知道对应表的。囧。。。过几天买本MySQL的，都快忘光了。。哈哈
@everhad: 把目的物种作为前缀，翻译的话靠软件了。。
其他回答(2)
0
桌面软件怎么快怎么做吧，只要SQL语句差不多就可以，无须考虑性能，内存啊等，和WEB完全不是一个等级的，
收获园豆：3
0
首先：
1.数据库推荐使用Sqlite，配合一些ORM框架，推荐使用DBEntry.Net
2.数据库设计字段不要用英文。
3.类命名不要用123等等
我看着有点乱，我给你截个图，你看我这个项目和你那个是不是差不多？
收获园豆：10
谢谢回答，我暂时不能发图片，好像要开博客的？
和你的表格还有点差距的，我的调查表主要是 “表头+Grid” 这种表，表头字段3到30个不等，而底下Grid一般10到20个列。
我一个问题是不好把握表头和底下Grid部分的内容是否需要分开成两张表存储，因为旧软件没有分，分开的话改动还不少。
另一个问题很无奈的，虽然知道尽量应该使用英文，但确实不像常见项目那些Customer、Order什么的，用户的需求文档中表就是 “表1 目的物种人工培植状况省级汇总表” 、“表2 目的物种所处植物群落概况表” 这样的。。。“表X”这样的就可以起到唯一标识的作用，就是在代码里Form1 的确别扭，但不知道能怎么叫了。。。而且很多表名字是一样的， 比如 "表2-1 目的物种记录表" "表2-2 目的物种记录表",一些表我还稍微能想到英文名称，但是更多的想不出来，为了统一就暂时都是——“FormN”这样的。。。
不知道这种情况算不算极端，有没有朋友也面对过这种大量调查表的项目？
@everhad:
如果我会这么设计：
每张“调查表格”对应一个类，然后类中字段对应要填的内容。然后Grid抽一个最多字段的公共类。
然后数据库表设计两个表，一表存“调查表格”的数据，内容采用JSON字符串存储，然后有个类别标识，用到的时候再解析成对应的调查表格类。主键采用GUID存储。
二表存Grid存储，和Gird的公共类设计保持一致即可。
类命名123这种，换做一个人可能不知道具体的含义，名字长短都可，主要是有意义。
“表1 目的物种人工培植状况省级汇总表” 、“表2 目的物种所处植物群落概况表”
我的做法是“RenGongPeiZhi” “SuoChuZhiWuQunLuo”
要的就是一眼能看出来对应的表，不需要去猜去查。
谢谢朋友，麻烦了！问题补充我列举了7张表，另一个项目就是表更多，基本一个情况。。
小软件本来也不打算纠结什么的，一年来具体的代码问题都是度娘谷歌，就是有关软件的一些设计和规范问题，真的是修炼无门，哎。。。
@everhad: 先积累经验，用的多了才知道问题在哪，然后考虑怎么改进就可以了。
