首页 新闻 会员 周边

MVC + EF 有一个稀奇古怪的问题,呵呵==大神么 走过路过不要错过啊。展现自身实力的机会来了。

0
悬赏园豆:10 [已解决问题] 解决于 2014-11-03 13:58

好吧,又一个想问的问题,但是发问的同时 又有些不详的预感

 

背景交代:

就是简简单单的创建订单的功能

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<>)

它的一部分数据是有的,需要完善另一部分数据(就像我前面所说的,)

 

 

我没分了,但是我有问题要问

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

算了的主页 算了 | 初学一级 | 园豆:3
提问于:2014-11-02 16:52
< >
分享
最佳答案
0

简化一点来说,你们严格遵循了数据库设计三范式的标准,设计了Order/OrderDetail一对多数据表。

在OrderDetail中只保留了ProductID,而没有ArtNo以及ProductName这些字段。

这个好不好又是另外一个很长的话题了,再说数据库不归你管,所以我们就当他就是这样了。

 

回到数据访问这一层,由于ProductID用户不友好,UI肯定需要显示ArtNo, ProductName这些内容。

那么问题来了,其实你所说的两种方式都可以。

1、是通过EF的连接查询

2、是将List(Product)或是每个查询过的Product Entity放入缓存中,由于IIS服务器长期运行+商品数量通过有限(一般不超过1万个,所占内存还好,几M吧)。第一次会有点难受。

 

性能方面的话,你还要考虑是物理分层还是逻辑分层。如果IIS与数据库不在一个物理机上,

或者甚至不在一个局域网内,则缓存优先。 

 

还有第三种方式,数据库视图。

收获园豆:10
爱编程的大叔 | 高人七级 |园豆:30839 | 2014-11-03 09:42

大叔,你咋这么体贴呢? 我要是妞的话,我一定会爱上你的

数据库的确实如大叔所说,由于一些特殊要求,商品的信息是不会更改的,名称之类的信息在使用中功能支持修改,但是业务中基本是不会改的,而产品包装的信息功能上就已经不支持更改了。所以商品一旦创建那么其数据就是稳定的了。这个具体的业务上详细原因等细节,个人尚不清楚,不过知道这些应该也足以开发和维护功能了。

所以呢 订单明细中 就确实也没有必要保存商品的更多信息了。

至于大叔说的:

【在OrderDetail中只保留了ProductID,而没有ArtNo以及ProductName这些字段。

这个好不好又是另外一个很长的话题了】

我猜测是在一些系统中商品的信息能够修改,且修改之后,不影响还原订单发生时的原始数据吧?

我是这么理解的。不知道对不对。肤浅的理解,见笑见笑

 

下面呢大叔回复我两种方法都可以

嗯,也认同,毕竟我也只找到这些方法。然后把,系统面向的使用者有一个特定范围吧,商品不是很多。

总共使用中的商品目前也不过 1300多个。所以缓存的话都懒得加,呵呵

IIS 与 数据库是在一个局域网内

 

【性能方面的话,你还要考虑是物理分层还是逻辑分层。】

说到这点上,我还真有些懵懂,没什么概念

刚网上搜索了下,也没找到什么有价值的东西。

这个,我斗胆问一下,是与框架相关的东西么?

 

【如果IIS与数据库不在一个物理机上,

或者甚至不在一个局域网内,则缓存优先。】

看来有必要研究下缓存了,即使目前暂时对缓存的需求很少。。。。呵呵。(之前自己学习过.net的缓存,不过长时间不用,忘的差不多了,嗯,需要复习下了)

然后就是确定一个问题

数据反问的话 通过局域网肯定比HTTP快吧(通过HTTP的话,比如odata)

那么

是这样的?

数据访问速度

硬盘  >  局域网  >  HTTP 是这个意思吧?

 

不知道我理解的对不对

算了 | 园豆:3 (初学一级) | 2014-11-03 11:10

@算了: 通过HTTP,比如OData,OData是一个比较慢的技术。(在我仅有的几篇文章中有一篇讲到OData),大概会比Linq/EF慢上一个数量级。(一个3秒,另外一个30秒这样)。

所以如果不是特别的原因(一种技术出现总有他的原因及需要他的人),还是用其他的技术吧。比如你应该可以直接用EF。

Client -  Application Server -- Database Server

你们现在是这样一个结构,三台物理机。通过缓存,则可以减少一部份的数据访问。

就是Client - Application Server (已经在内存里面了,直接返回)

爱编程的大叔 | 园豆:30839 (高人七级) | 2014-11-03 11:34

@爱编程的大叔: 好的。再次感谢大叔的 热心回复。十分感谢

(感觉需要学习的东西越来越多,越学越多)

算了 | 园豆:3 (初学一级) | 2014-11-03 13:45
其他回答(1)
0

文采飞扬啊

Chaoa | 园豆:643 (小虾三级) | 2014-11-02 20:55

给点实质性的回复吧

  比较郁闷 所以写的随意一些。

支持(0) 反对(0) 算了 | 园豆:3 (初学一级) | 2014-11-02 21:57
清除回答草稿
   您需要登录以后才能回答,未注册用户请先注册