面试题 设计业务逻辑层和数据库结构
面试题   设计业务逻辑层和数据库结构
如题:
对于业务逻辑层   描述出相关接口即可
订单号   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看看这两个保存英文和中文的情况
。。。。。