您可以阅读我其他的发明创想：
使用遥控器控制汽车，实现高难度的泊车（发明畅想）
取款机钱箱没有钱提示(发明畅想)
微型电动轿车(发明畅想)
智能电视的设想（发明畅想）
压缩空气动力自行车
首先我声明：我并不知道有没有人发明空中投影技术（例如使用激光在空中制造出图像），也就更不知道实现的技术了。我只是想到这种技术的应用。
有次我看见一个小车想左转掉头，于是在左车道停下来，后面的车马上停下试图调整到右侧超过，再后面的车呢看不到第一辆车，于是想从左侧超，可惜突然看见前面还有一个车，赶紧刹车，很危险。
于是，我就想，如果前面的车顶（空中，而且要稍微高一些）投影出一个左方向箭头，那岂不是很好，后面的车虽然看不见前面的车，但是可以看见空中有个投影，知道危险要慢下来。
同样的道理，还可以将箭头投影到前面的道路上，在你从一个小巷子要出来时很有用。
Linq to SQL内置缓存功能，简单的说，当你查询了一次某个键的数据后，再次查询时linq to SQL的引擎不再向数据库发送SQL，例如：
//下面是使用LinQ to SQL 的例子，context2是派生自System.Data.Linq.DataContext的实例
ErpLinQContextDataContext context2 = new ErpLinQContextDataContext();
//SQLServer事件探查器拦截到SQL语句的执行
//exec sp_executesql N'SELECT TOP 1 [t0].[emp_id], [t0].[fname], [t0].[minit], [t0].[lname],
// [t0].[job_id], [t0].[job_lvl], [t0].[pub_id], [t0].[hire_date]
//FROM [dbo].[employee] AS [t0]
//WHERE [t0].[emp_id] = @p0', N'@p0 varchar(9)', @p0 = 'PMA42628M'
employee p3 = context2.employees.First<employee>(p => p.emp_id == "PMA42628M");
//当我再次执行相同的查询时，LinQ to SQL 不再向SQL Server发送查询了。
employee p4 = context2.employees.First<employee>(p => p.emp_id == "PMA42628M");
而且，
这两个实例是同一个实例：
//返回的对象是同一个实例
bool b2 = object.ReferenceEquals(p3, p4); //=true;
p3.lname = "New Last Name";
bool b4 = (p4.lname == "New Last Name"); //=true;
当然，如果你使用不同的Context实例查询时，缓存功能将实效。
好，让我们再看看ADO.NET Entity Framework beta 3：
//pubsEntites是 ADO.NET Entity Framework 的System.Data.Objects.ObjectContext派生对象
pubsEntities context = new pubsEntities();
//下面语句执行时，SQLServer事件探查器拦截到SQL的执行
//SELECT TOP 1 [Extent1].[emp_id] AS [emp_id], [Extent1].[fname] AS [fname], [Extent1].[lname] AS [lname],
// [Extent1].[hire_date] AS [hire_date], [Extent1].[job_id] AS [job_id], [Extent1].[pub_id] AS [pub_id]
//FROM [dbo].[employee] AS [Extent1]
//WHERE N'PMA42628M' = [Extent1].[emp_id]
Employee p1 = context.EmployeeSet.First<Employee>(p => p.EmployeeId == "PMA42628M");
//SQLServer事件探查器 发现SQL再次被执行
Employee p2 = context.EmployeeSet.First<Employee>(p => p.EmployeeId == "PMA42628M");
//测试发现，虽然ADO.NET Entity Framework执行了两次SQL，但是他们却返回了完全相同的实例
bool b1 = object.ReferenceEquals(p1, p2); // = true;
测试的结果是，ADO.NET Entity Framework（以下简称AEF）没有使用缓存，而是再次执行SQL，但是你要注意：
两次查询的实例竟然是同一个。
从Context功能上看，他肯定持有上次查询的结果，他没有使用缓存，我只能认为可能AEF被设计成三层应用，那么他很担心其他的进程将数据改了，所以不使用缓存，当发现数据并没有改后，还是使用原先的实例，这个想法对吗？
我们再看看另外一个代码：
//如果使用不同的上下文更新的数据，
pubsEntities context4 = new pubsEntities();
Employee p10 = context4.EmployeeSet.First<Employee>(p => p.EmployeeId == "PMA42628M");
p10.LastName = "Context4 changed data";
context4.SaveChanges();
//旧的context再次查询时。
Employee p11 = context.EmployeeSet.First<Employee>(p => p.EmployeeId == "PMA42628M");
b1 = object.ReferenceEquals(p1, p11); //= true why??
b1 = (p11.LastName == "Context4 changed data"); //= false p11.LastName = "New Last Name"
难以置信，
AEF重新执行了SQL，但是置新的更改而不闻，仍然返回旧的数据。这个算是Bug吗？
我不知道哪位达人能够解释这个问题？当然，这个问题我也询问了MS，他们的技术人员还未做出满意的答复。
我不是那种“做好事不留姓名” 的那种，
纪念一下。
但还是少些这种捐款好，我的意思是希望天下太平。都不用捐款才是最好。
希望中国少些灾难，军队能够提高能力，设备先进些。
请先参考《相信自己，我能》 关于读取性能的测试
今天对插入的性能做了比较，和我预期的一样，Torridity的性能和其他的产品基本打平手，而Entity Framework一样是糟糕的成绩。
为什么认为会打个平手呢？因为插入1万比记录，意味这连续发送1万次SQL，在没有提别糟糕的程序下，基本上SQL语句的执行花去了几乎大部分的时间，程序本身的优化所得到的提升几乎微乎其微。
下面是测试结果：
再次失望ADO Entity Framwork的性能，太糟糕了
关于元数据结构
自动创建的代码包含一个派生自ObjectContext的对象，他有点像一个Workspace，主要包含连接、元数据和状态管理等；
ObjectContext包含一个MetadataWorkspace属性，记录了所有的元数据信息，有几种类型：
C Space: 很全，包括数据类型（例如Byte）、函数(例如Max）、实体类型（例如Order）；
CS Space：null?没有吗
OC Space：纯数据类型，一般13个；
S Space：包括数据类型和实体类型。
你可以像下面这样的代码获取元数据
EntityType c2 = c.MetadataWorkspace.GetItem<EntityType>("DcmsCore2_TestModel.Customer", System.Data.Metadata.Edm.DataSpace.CSpace);
枚举出一个元数据对象，怎么知道是描述什么的呢？BuildtInTypeKind属性可以告诉你，常见的有：
PrimitiveType : 原生数据类型，例如描述string的
EntityType ：实体类型，一般是ClrEntityType的实例，例如描述order
MetadataProperty : 属性，例如描述Order的属性OrderId；
Facet ：特性，用来描述是否允许null，或缺省值之类的东西，有点像CLR里面的Attribute
看见一文章《
比亚迪员工的心声》，原文是：
首先声明一下：本人是比亚迪公司的一名工程师，看到这么多的争议，不管是好的还是不好的评论，至少证明大家还是关注这个公司的汽车。提建议是好的，但是别带上个人的主观情趣，说句实在话我也不知道公司的车到底好不好，但是我知道的是我们确实一直在改善，也许你们觉的这个车这里缝隙大，那里配合不好，那里又怎么差的。那我想问你们一句：你们的标准是什么呢？如果你拿宝马奔驰来做标准那我劝你暂时还是不要来发表了，因为我们还没有达到那种高度，我们是民营企业，要养活十几万人，换句话说我们要生存。从开始的F3到现在的F6如果说没有改进的话我把头给你们当球踢，但是改进要一个过程，不是你今天说要改明天就可以改好了，可以说理论的东西我们可以设计到一丝不差，但实际加工出来就不是你想的那样了。每一个改进都要经过N多的程序。举个很简单的列子吧：如果要改进一个地方的配合间隙，是不是要修改其中一边的尺寸，是不是涉及到模具的尺寸，这个东西是钢铁做的，不是泥巴你捏一下它就变长了。光是这样的模具拆下来都要很长的时间更不要说加工了。所以要理性的看待问题。就像很多的F3车主说的一样，现在出来的F3比以前的工艺好多了。确实如此，
因为我们一直在努力。我们不止做汽车，我们做电池，做IT，我们的IT已经做到了0.005MM的公差。所以我们很有信心把汽车这一块做好。
当然更希望广大车友提意见到我们公司。
==============================================
我的看法是：
好热闹啊，我也插一句，我就不愤青了 
说到底，商家要赢，拼到底就是看谁能够持久的提供高性价比的产品和服务，
例如，在6万这个价位上，我造的汽车比别的汽车看起来就是漂亮些，质量就是好些，就会大把有人买。
人是贪心的，很多客户买了10元的东西也会要求送货上门，为什么不可以呢？盒饭就可以，但是如果你300元买洗衣机，还要送货上面就没有人愿意了。
如果这个时候有厂家说，300元我可以卖给你洗衣机，但不提供送货上门，我敢向上帝保证：还是有人要求送货上门的，因为人是贪婪的。你可以想象，如果这个厂家坚持不送货上门，我相信结果是：客户一边骂，一边在买，然后心中窃喜，骂完了之后又打电话叫上他的大哥小弟赶快来抢。
好，我们继续，很不幸，这个厂家刚开始买的300元的洗衣机质量还是不错的（所谓质量不错，是指通常理解的不经常坏），后来觉得没有利润就开始偷工减料，质量不行了，但商家凭良心说，这个洗衣机只有10元利润了，但是这个时候客户会买单吗？不会，在这个例子中客户是不会的，为什么？因为客户愿意掏更多的钱买个质量好的洗衣机。这个钱客户觉得他掏的起掏的值，就像你可以理解一个普通的白领不会买巷子角落的1毛钱的烧饼，即使天地良心，这个烧饼成本就已经是1毛了。
我们再假设，人的智慧太厉害了，很多的厂家经过努力，他们的洗衣机也卖到300了，质量一样的好，那么这个厂家继续说，我不送货上门，还有人了他吗？还是300，还是不送货上门，为什么结果不一样了。
总之，在保证基本利润的基础上，给客户最大化的利益才是商家持久发展之道。
大家也可以参考 施乐和佳能 关于复印机的案例。