首页新闻找找看学习计划

我觉得我这样设计进销存很SB也!该如何改进?

0
悬赏园豆:30 [已解决问题] 解决于 2012-07-31 14:35

首先建立基础档案:客户 供应商 客户 员工 公司信息 部门信息 商品 信息 等等等。。

数据库:

每个对象建立不同的表,有关联的用一个字段联系起来,比如 仓库信息表 里面 会包括一个 分店ID,及该仓库属于哪个分店,员工信息表有个字段 部门ID,及该员工属于哪个部门,

 

实体层:根据数据库表中 一一对应建立 实体层对象。 如:员工类 商品档案类 部门类 等等。

数据访问层:也跟数据库一一对应,然后没一个类里面各写各的 增 删 改 查 及别的方法。

业务层:暂时不考虑业务,只是简单的 增 删 改 查 等方法,调用 数据访问层 的方法 返回必要的信息。

UI层:不多说了。

 

我感觉这样太SB了。 完全没有什么面对对象的东西啊。 什么继承 多态 接口 泛型,我都理解,但是就是不知道该怎么把这些东西 很好的运用到 设计里面去。 更别谈设计模式。 请不要说看我们需求, 我的 需求就是做一个进销存软件,像收银软件一样的。

 

如果是你来做你会怎么做?

变形精怪的主页 变形精怪 | 初学一级 | 园豆:3
提问于:2012-05-12 20:00
< >
分享
最佳答案
0

面向对象 并不是一切.不要为了面向对象而面向对象.

不要为了 设计而设计,

软件的智能程度 映射 程序员的智商.

收获园豆:5
waninlezu | 小虾三级 |园豆:661 | 2012-05-14 14:20

兄台,这类话听多了, 对我目前的水平来说 这太深奥了。我 需要你的 回答 理解。。

变形精怪 | 园豆:3 (初学一级) | 2012-05-23 16:06
其他回答(2)
0

首先一个问题,继承 多态 接口 泛型这些技术思想全部用到你的软件并不见得是一件好事。这些思想的主要目的其实还是在于协作,扩展,维护上面,适度把握即可。

我觉得对于你的这种设计大体思路是没有问题的。

Model,DAL,BLL,UI。那么如何让你的代码更清晰合理的?

泛型:上面你也提到了,说是每个类里面要写增删改查,这样是不是非常的冗余呢?是的!解决方案就是通过泛型方式提取公共方法,封装到一个泛型类里面实现所有的基础操作。

public class DAL<T> where T : new() 

......

继承:当你在实际的业务逻辑开发的时候,你会发现有的功能仅仅采用增删改查是不能打到目的的,或者是会很绕弯子的,而且每一个Model(表)的操作有区分的,有的可能仅仅采用基础的增删改查即可完成所有的操作,而有的却不能。那么继承就可以派上用场了。在复杂操作的类中我们只需要继承上面的泛型类即可,这样我们不但拥有了泛型类提供的所有方法,而且可以有自己的特定方法。

接口:一种规范,这个不必多说了吧,例如有了接口,你可以方便的切换你的数据库实现技术(ADO,Nhibernate,EF)而不需要对其他层做任何的改动。

多态:实际上可以理解成泛型

收获园豆:20
jackchain | 园豆:95 (初学一级) | 2012-05-12 22:07

多态:实际上可以理解成泛型 ?是錯誤的。

支持(0) 反对(0) 無限遐想 | 园豆:3740 (老鸟四级) | 2012-05-13 08:36

@無限遐想: 已经写了一篇详细的文章:http://www.cnblogs.com/qidian10/archive/2012/05/13/2497627.html

支持(0) 反对(0) jackchain | 园豆:95 (初学一级) | 2012-05-13 10:51
0

关联对象的一对多。多对多啊。 DAL<T> 完全不靠谱 只是最后的实现手段。

先把对象设计好。一切都很明白了。

收获园豆:5
````` | 园豆:14268 (专家六级) | 2012-05-13 08:44

靠谱,就像你说的把对象设计好

支持(0) 反对(0) jackchain | 园豆:95 (初学一级) | 2012-05-13 10:52

@jackchain: 

设计好对象的m:n 关系,系统之间的逻辑关联就反映出来了。

上面所说的DAL<T>只是实现了基础的CURD的操作。

但是这个有很高的个人臆想成分。或者只是会用泛型的一种展示。

看DAL<T>不如看Repository<T>。这里是不需要BLL的累赘的。

想了解具体的看下MVC + Repository 

支持(0) 反对(0) ````` | 园豆:14268 (专家六级) | 2012-05-13 11:01
清除回答草稿
   您需要登录以后才能回答,未注册用户请先注册