面试题 设计业务逻辑层和数据库结构

Question

面试题 设计业务逻辑层和数据库结构
如题:
对于业务逻辑层 描述出相关接口即可
订单号 xxxxxx   订单日期 xxxxxx
客户   xxxxxx   总金额   xxxxxx
商品名称    单价    数量   总金额
xxxxxx      xx      xx     xx*xx
xxxxxx      xx      xx     xx*xx
... ...
我设计的数据库结构:
单头表 ->  订单号 varchar(...) 订单日期 datetime 客户 varchar(...) 总金额 decimal(...)
单体表 -〉 订单号 varchar(...) 商品编号 varchar(...) 商品名称 varchar(...) 单价 decimal(...) 
           数量 decimal(...) 总金额 decimal(...)     
我设计的业务逻辑层:
public class order
{
 public DataTable sel(orID) {...} //制定订单号查询订单
 public int del(orID) {...} //删除指定订单 返回受影响行数
 ... ...
}
我觉得我写的数据库结构还行 至于业务逻辑层吗 呵呵 估计是丢人了
诸位帮看下

Answer 1

业务逻辑没有sel这种操作。订单本身就“存在”明细部分，至于是否查询出来的，不是业务逻辑设计内容，是将来由程序员实现时才会被说明的，在Order中并没有。一个订单的明细，基本上使用定义：  public OrderDetail[] Items{get;}或者：  public List<OrderDetail> Items{get;}同时，OrderDetail类型中也会有一个属性
  
  public Order Parent{get;set;}在Order中也不需要有删除操作。当从持久化机制中删除OrderDetail的时候，会根据Parent来更新订单中的对明细的关联（或者根本不需要更新），但是总之这不是业务逻辑内容。
上述设计没有没有考虑任何业务规则，实际的东西应该比这个复杂10倍以上。
数据库设计比较低级。基本上，设计好业务逻辑和接口，数据库结构就可以由反射程序自动产色和那个和升级更新了，不需要由人工去产生和维护。

Answer 2

数据库结构就可以由反射程序自动产色和那个和升级更新  --> 
                           数据库结构就可以由反射程序自动产生和升级更新在从业务逻辑到持久化程序的映射的程序中，应该考虑对象的继承、关联、索引、级联更新、c/s处理、缓存等，仅仅会创建数据库表，实在是做得太少了。

Answer 3

单头表 ->  订单号 varchar(...) 订单日期 datetime 客户 varchar(...) 商品编号 varchar(...) 数量 int(...) 总金额 decimal(...)单体表 -〉  商品编号 varchar(...) 商品名称 varchar(...) 单价 decimal

Answer 4

bwangel(永远的裤衩),他分单头和单体是对的，明细表关系。
不过看到楼主的类和两个方法的命名我就郁闷，如果是面试，就因为这个会很容易被刷掉。
至少要大写类名吧？SP1234分明是要让楼主用一套ORM工具……
我觉得如果细表对象(OrderDetail)不需要用到主表对象(Order)的话,也不一定需要建立Parent属性。
更典型的是如果系统并不关心OrderDetail对象（系统粒度为订单级），设计的时候也有可能不建立OrderDetail类型。Order中的item只是Product的一个简单引用。
不过楼主这里有价格，数量，和总价，单独的OrderDetail对象还是需要的。
当然从完备对象关系的角度看，sp1234说的很有道理。

Answer 5

我热泪盈眶 一是热心人太多 二是我肯定面试over了 ... ...
我固执的认为我的表设计得还凑合 就是业务逻辑层一团糟

Answer 6

我热泪盈眶 一是热心人太多 二是我肯定面试over了 ... ...
我固执的认为我的表设计得还凑合
varchar nvarchar看看这两个保存英文和中文的情况
。。