面试题 设计业务逻辑层和数据库结构
如题:
对于业务逻辑层 描述出相关接口即可
订单号 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) {...} //删除指定订单 返回受影响行数
... ...
}
我觉得我写的数据库结构还行 至于业务逻辑层吗 呵呵 估计是丢人了
诸位帮看下
------解决方案--------------------------------------------------------
业务逻辑没有sel这种操作。订单本身就“存在”明细部分，至于是否查询出来的，不是业务逻辑设计内容，是将来由程序员实现时才会被说明的，在Order中并没有。
一个订单的明细，基本上使用定义：
public OrderDetail[] Items{get;}
或者：
public List <OrderDetail> Items{get;}
同时，OrderDetail类型中也会有一个属性
public Order Parent{get;set;}
在Order中也不需要有删除操作。当从持久化机制中删除OrderDetail的时候，会根据Parent来更新订单中的对明细的关联（或者根本不需要更新），但是总之这不是业务逻辑内容。
上述设计没有没有考虑任何业务规则，实际的东西应该比这个复杂10倍以上。
数据库设计比较低级。基本上，设计好业务逻辑和接口，数据库结构就可以由反射程序自动产色和那个和升级更新了，不需要由人工去产生和维护。
------解决方案--------------------------------------------------------
数据库结构就可以由反射程序自动产色和那个和升级更新 -->
数据库结构就可以由反射程序自动产生和升级更新
在从业务逻辑到持久化程序的映射的程序中，应该考虑对象的继承、关联、索引、级联更新、c/s处理、缓存等，仅仅会创建数据库表，实在是做得太少了。
------解决方案--------------------------------------------------------
bwangel(永远的裤衩),他分单头和单体是对的，明细表关系。
不过看到楼主的类和两个方法的命名我就郁闷，如果是面试，就因为这个会很容易被刷掉。
至少要大写类名吧？
SP1234分明是要让楼主用一套ORM工具……
我觉得如果细表对象(OrderDetail)不需要用到主表对象(Order)的话,也不一定需要建立Parent属性。
更典型的是如果系统并不关心OrderDetail对象（系统粒度为订单级），设计的时候也有可能不建立OrderDetail类型。Order中的item只是Product的一个简单引用。
不过楼主这里有价格，数量，和总价，单独的OrderDetail对象还是需要的。
当然从完备对象关系的角度看，sp1234说的很有道理。
------解决方案--------------------------------------------------------
我热泪盈眶 一是热心人太多 二是我肯定面试over了 ... ...
我固执的认为我的表设计得还凑合
varchar nvarchar看看这两个保存英文和中文的情况
。。。。。