项目总结报告1 实体框架之罪行

 项目简介.主站www.hd01.com.cn  平台main.hd01.com.cn

《HD01活动定制引擎V1.0》是优秀的网上活动定制和推广系统。利用它，不需要进行任何研发，就可以在3～10分分钟内设计、定制多种常见的网上活动。

 

• 网上活动: 

 

由共同目的联合起来，部分或全部基于网络而完成的一定社会职能的动作的总和。网上活动由目的、动机和动作构成，具有完整的结构系统。

 

• 网上活动的营销优势:

 

  网上活动本质上是一种营销推广手段，以有一些独特的营销优势：

用户喜欢参加：网上活动有精彩互动过程，有奖品，用户喜欢主动参加；

深度宣传推广：网上活动有精彩过程，产品和服务本身的卖点能在活动过程相结合， (如答题活动的题目可以以产品的特征为题干)。用户在参与过程中主 动的或不知不觉就深度掌握了产品和服务。

推广和销售结合：网上活动加上网上支付的功能，就可以实现推广与销售相结合，一箭双雕。

 

• 常见的网上活动:

 

l答题类：知识竞赛、问卷调查、投票、竞猜； l推广类：团购、招聘、有奖注册、免费领取，试用、促销、秒杀、优惠卷； l 征集类：摄影作品征集、DV作品征 集、标志、LOGO、吉祥物等平面作品征集、广告语，广告词，宣传语，口号，短信征集、网络征文、动画，彩信征集、歌词歌曲征集； l 游戏类：每一种休 闲游戏加上成绩排行都可以看成是一种活动； 生活中无处不活动，以上只是部分列出。 

以下是用活动创建平台创建、主办外包、主办方自行研发三种活动创建方法在成本、时间和营销效果上的对比：

对比点		用活动创建平台创建	主办方外包	主办方自行研发
活动类型		20～60种，按需选择	每次只能1种	每次只能一种
创建成本	设计成本	只需考虑活动如何举办，告诉引擎即可，会打字就行。	需要和外包人员沟通，设计越复杂，成本越高	需请专人设计每个 活动细节页面
	研发成本	无需写一行代码	需要和外包人员沟通，功能越复杂，成本越高	需请研发人员研发 每个功能
	界面美化成本	只需提供一些产品或 服务的图片	需要提供一些产品或 服务的图片给外包方	需聘请美术人员进 行每个网页的美化
	定制成本	定制功能极强，0成本使用	定制要求越高，成本也就越高	一般无力支持定制功能，而且成本高
上线时间		1小时即可上线	15～60天或更多	15～60天或更多
营销效果	中奖面	支持小额发奖，中奖面大	小	小
	病毒式传播	支持奖励邀请好友参加活动	有的支持，有的不支持	有的支持，有的不支持
	自适应搜索引擎	能自适应搜索引擎	有的支持，有的不支持	有的支持，有的不支持

 

以下是具体活动功能上的对比：

对比点		HD01活动定制引擎	自主研发	外包
活动界面表现	风格	无需写代码，主办方可在活动的任何时间调整活动风格。	每次活动，需要独立研发，不能复用；研发完就固定死了，不能调整。	每活动活动，需要独立研发，不能复用；研发完就固定死了，不能调整。
	布局	无需写代码，主办方可把首页任意切换成支持 1：2：1，1：3，3：1的布局。	布局是死的，不能调	布局是死的，不能动
	模块	无需写代码，主办方可自定义自己的大图，列表、文本、声音、动画、视频模块，并可放在页面的任何地方	不支持	不支持
	头尾、背景	主办方可随时对任一活动的头、尾及背景进行自定义	可以做到，但需要写代码	可以做到，但需要写代码
	导航	主办方可随时扩展活动的主栏目，以满足形式发展的需要	可以做到，但需要写代码	可以做到，但需要写代码
活动信息展现	活动基本信息	主办方可随时扩展活动基本信息，会打字就行	需要专业人员才能做到	需要专业人员才能做到
	组织者	主办方可随时扩展组织者信息，会打字就行	需要专业人员才能做到	需要专业人员才能做到
	联系方式	主办方可随时扩展联系方式，会打字就行	需要专业人员才能做到	需要专业人员才能做到
注册	系统注册项	主办方可从数十项注册项里随时选择自己需要的注册项，以针对性的收集参与者的信息。	一但确定，不能更改	一但确定，不能更改
	自定义注册项	如果系统提供的注册项不能满足需求，主办方可自定义	无法做到	无法做到
活动 逻辑		HD01提供了60种不同的活动逻辑供主办方使用，并可扩展。主办方无需编码	只能有一种	只能提供一种
新闻 中心	新闻分类	无需编码，主办方能随时增删改活动的新闻分类	需要大量编码	需要大量编码
	新闻内容管理	主办方能随时增删改新闻内容，	需要大量编码	需要大量编码
奖项 奖品	奖项设置	主办方能随时增删改奖项设置	需要大量编码	需要大量编码
	奖品设置	主办方能随时增删改奖项设置	需要大量编码	需要大量编码
评奖方式	专家评奖	主办方能任意组合这三方评奖方式进行奖项评定。	只能编码实现里面的一至两种，且编码后不能移植到别的活动类型	只能编码实现里面的一至两种，且编码后不能移植到别的活动类型
	按活动成 绩评定
	抽奖
网上 支付		可任意选择多种网上支付方式	一般不支持	一般不支持
第三方数据交换		支持与第三方网站进行用户信息交换	不支持	不支持
BBS		每个活动均有自己的BBS	没有	没有
动转静		重要动态页面均转成静态页面访问	不支持	不支持

 

个人评价:

通过半年的开发,项目已经运营.但回想起来,整个项目中遇到了许多的问题,还好需求策划上一直很好(原因在于老板原来就是一个产品总监且目前的策划都很有逻辑性),所以对于开发人员而言没有吃苦.问题在于微软的实体框架EF让人简直痛恨至极(个人愚见),

其一:效率(如果有人做过测试我想都和我有同感,这增删改查无处不见其效率之低下,我想如果说你要执行原生态的sql表达式 或者较为其次的LINQ,根本就没有用它的必要性,更何况linq是一个值得争议的技术,有人测过他的效率就知道了.

单凭实体框架的效率问题,在一个并发性能可能上万的项目中,简直BS至极) 

其二:数据冗余(如果你查询一个或两个字段,你的查询结果真够要命....不用多说)

其三: 项目版本更新问题(如果你的项目版本更新,你需要重新生成数据库(这里说的是ModeFirst),你需要做哪些事情?自己想想)

当然也有其有点:但是我们完全可以用powerdesigner代替它.

 

教训:简单实现的东西或许用了其他东西作为交换(性能).最新的不一定是最好的.