好吧,又一个想问的问题,但是发问的同时 又有些不详的预感
背景交代:
就是简简单单的创建订单的功能
entity
Order
OrderDetail
订单明细实体中肯定要有 商品ID,商品包装,订单数量 这些的
当然了 还有EF的导航属性
public ICollection<Product> Product{get;set;}
那么页面在显示的时候肯定是需要显示更多的东西
比如商品的名称(如上所说通过 OrderDetail的 Product导航属性存储)
而“商品名称”这个数据,在提交订单的时候 不需要保存到 OrderDetail表
所以也就不提交这个数据了
--------
以上做法应该没有什么问题吧
当然一切正常的时候自然是没有问题
但是一旦发生异常
需要重新显示页面,并把用户编辑的数据也显示出来的,我想这个也是无所厚非的吧
那么问题来了
由于商品名称 这个数据没有提交,所以在发生异常的时候,需要重新获取
怎么获取呢?这是个问题啊
一开始我是这样做的
orderDetails.ForEach(x => x.Product =
(from p in productRepository.Products
where p.ProductID == x.ProductID
select new Product
{
ProductID= p.ProductID,
ProductName = p.ProductName
}).Single());
我想有点开发经验的人都能看出来,这个方法有一个问题
就是对每一条商品明细都会有一个数据库访问
这样做的话,肯定是一个败笔的
所以呢
我自己又改善了下
(这里就不贴代码了)
就是将订单明细中的商品信息一次查询出,结果肯定是个列表
List<> tempProducts ........................
for{ 【遍历商品明细的每条数据】
item.Product = tempProducts.Where(x=>x.ProductID == item.Product).Single();
}
这样的话,只需要一次数据库访问
这是我想到解决办法
---------------------
那么说了这么多。。。。。。。。。。。
我的问题是什么呢?
那么问题来了,挖掘机技术哪家强?
呵呵 开个玩笑,是你的话你会怎么做???
是把 商品名称这类不需要跟新到数据的数据也提交到后台呢?(当然这样网络传输的数据就多了一些)
还是和我想的一样,在后台再次访问数据库获取呢?
(少网络阐述,但多了一次数据库访问)
如果是像我一样,重新获取的话
你会怎么获取呢?
不知道EF有么有能力处理这种情况
一个列表(List<>)
它的一部分数据是有的,需要完善另一部分数据(就像我前面所说的,)
我没分了,但是我有问题要问
简化一点来说,你们严格遵循了数据库设计三范式的标准,设计了Order/OrderDetail一对多数据表。
在OrderDetail中只保留了ProductID,而没有ArtNo以及ProductName这些字段。
这个好不好又是另外一个很长的话题了,再说数据库不归你管,所以我们就当他就是这样了。
回到数据访问这一层,由于ProductID用户不友好,UI肯定需要显示ArtNo, ProductName这些内容。
那么问题来了,其实你所说的两种方式都可以。
1、是通过EF的连接查询
2、是将List(Product)或是每个查询过的Product Entity放入缓存中,由于IIS服务器长期运行+商品数量通过有限(一般不超过1万个,所占内存还好,几M吧)。第一次会有点难受。
性能方面的话,你还要考虑是物理分层还是逻辑分层。如果IIS与数据库不在一个物理机上,
或者甚至不在一个局域网内,则缓存优先。
还有第三种方式,数据库视图。
大叔,你咋这么体贴呢? 我要是妞的话,我一定会爱上你的
数据库的确实如大叔所说,由于一些特殊要求,商品的信息是不会更改的,名称之类的信息在使用中功能支持修改,但是业务中基本是不会改的,而产品包装的信息功能上就已经不支持更改了。所以商品一旦创建那么其数据就是稳定的了。这个具体的业务上详细原因等细节,个人尚不清楚,不过知道这些应该也足以开发和维护功能了。
所以呢 订单明细中 就确实也没有必要保存商品的更多信息了。
至于大叔说的:
【在OrderDetail中只保留了ProductID,而没有ArtNo以及ProductName这些字段。
这个好不好又是另外一个很长的话题了】
我猜测是在一些系统中商品的信息能够修改,且修改之后,不影响还原订单发生时的原始数据吧?
我是这么理解的。不知道对不对。肤浅的理解,见笑见笑
下面呢大叔回复我两种方法都可以
嗯,也认同,毕竟我也只找到这些方法。然后把,系统面向的使用者有一个特定范围吧,商品不是很多。
总共使用中的商品目前也不过 1300多个。所以缓存的话都懒得加,呵呵
IIS 与 数据库是在一个局域网内
【性能方面的话,你还要考虑是物理分层还是逻辑分层。】
说到这点上,我还真有些懵懂,没什么概念
刚网上搜索了下,也没找到什么有价值的东西。
这个,我斗胆问一下,是与框架相关的东西么?
【如果IIS与数据库不在一个物理机上,
或者甚至不在一个局域网内,则缓存优先。】
看来有必要研究下缓存了,即使目前暂时对缓存的需求很少。。。。呵呵。(之前自己学习过.net的缓存,不过长时间不用,忘的差不多了,嗯,需要复习下了)
然后就是确定一个问题
数据反问的话 通过局域网肯定比HTTP快吧(通过HTTP的话,比如odata)
那么
是这样的?
数据访问速度
硬盘 > 局域网 > HTTP 是这个意思吧?
不知道我理解的对不对
@算了: 通过HTTP,比如OData,OData是一个比较慢的技术。(在我仅有的几篇文章中有一篇讲到OData),大概会比Linq/EF慢上一个数量级。(一个3秒,另外一个30秒这样)。
所以如果不是特别的原因(一种技术出现总有他的原因及需要他的人),还是用其他的技术吧。比如你应该可以直接用EF。
Client - Application Server -- Database Server
你们现在是这样一个结构,三台物理机。通过缓存,则可以减少一部份的数据访问。
就是Client - Application Server (已经在内存里面了,直接返回)
@爱编程的大叔: 好的。再次感谢大叔的 热心回复。十分感谢
(感觉需要学习的东西越来越多,越学越多)
文采飞扬啊
给点实质性的回复吧
比较郁闷 所以写的随意一些。