Categories

Links

.NET Framework 3.5 June 2007 中linq to sql 的新东西

.NET Framework 3.5 June 2007  中linq to sql 的新东西

1. 现在能够支持IDataErrorInfo接口了
早先主要是entity类不 支持this 索引属性

2. DataContext有个获得ChangeSet的方式了,大家可以看看早先是如何 通过reflect来获取的
http://dotnetslackers.com/articles/csharp/GettingChangedEntitiesFromLINQToSQLDataContext.aspx

现在就可以使用

  ChangeSet changeSet=db.GetChangeSet();
  foreach(Object obj in changeSet.RemovedEntities){
  }
  foreach(Object obj in changeSet.ModifiedEntities){
  }
  foreach(Object obj in changeSet.AddedEntities){
  }
 
3. entity的 OnValidate方法
在DataContext.SubmitChanges时触发,不过在我测试中发现很奇怪,就是entity没有改变它也触发了!!要是OnValidate中有访问数据库的行为,那还不要命,如果datacontext中有大量的entity的话.


写法很简单
public class YourEntity{

 private void OnValidate(){
  //你的validate逻辑
 }
}

 同样你可以实现OnLoaded ,这个方法在entity被load时被调用,在sqlmetal生成的代码中,OnValidate,OnLoaded是作为partial 方法声明的.

4. DataContext.CommandTimeout 

代理provider的CommandTimeout,其作用就不多说了

 

5. sqlmetal 生成的代码,有很大改变,现在,他为每一个属性都生成OnxxChanging和OnxxChanged partial method ,通过在构造函数中调用OnCreated partial 方法,你可以在partial  class 中实现改方法来达到类似DataTable.NewRow的效果. 注意 sqlmetal现在生成的代码使用了partial method 特性,关于partial method 大家可以参见 http://www.infoq.com/cn/news/2007/04/PartialMethods

 

以下是一些随手发现的东西

命名空间有改变,现在TableAttribute都被移动到Sytem.Data.Linq.Mapping,而StoreProcedureAttribute已经被删除,只使用Function

原来的System.Data.Linq.IPropertyChanging接口现在被移到到了System.ComponentModel中

IQueryable 已经没有CreateQuery,Execute方法了,现在这些由IQueryProvider的实现来完成,原来的动态查询的例子,source.CreateQuery,source.Execute都要相应的改为 source.Provider.CreateQuery,source.Provider.Execute才行

[2007-07-09 23:00:40 | Author:jiangjianxiao ] [] 2 comments

dlr script engine

如果你下载了最新的ironpython 2 (a1和a2),你会发现早先1中 教程中的:  IronPyton as applications scripting engine 一节不见了.老的1.x中的方法也通不过了.

那么,我们要怎样将 ironpython作为脚本引擎嵌入到我们的应用程序中呢 ,答案在Microosft.Scripting.dll中 的

using Microsoft.Scripting

Script.SetVariable('x',5);
Script.Execute('py','print x');

就是这样简单

btw : ironpython 2.0的a2版本由于由于没有修改language provider的版本(应该是2.0.0.200而不是早先的2.0.0.100),不能运行以上代码

Script 解决了几个问题
1. 首先是生存期的问题,Script将所有的调用都转发到ScriptDomainManager.CurrentManager,CurrentManager是ScriptDomainManager的一个singleton实例. 这样,省去了我们自己维护脚本引擎生存期的必要.

2. 正如ScriptDomainManager的命名,它是一个脚本引擎的管理器. 目前,它通过ScriptEnvironmentSetup 注册了ironpython,js,vb,ruby ,显然,目前仅ironpython可用.

现在,可以真正的替换dotnettools workflow中的脚本功能了,我目前做了以下修改

1. 移去了早期的脚本配置功能(早期用于预先引入assembly和导入namespace)
2. 移去了ironpython实现,重新实现基于Microsoft.Scripting的ScriptingValidator,ScriptingFunctionProvider,ScriptingRegister,ScriptingCondition
下面是新的配置文件,大家可以看到脚本的function,condition的type为scripting,如果没有设置脚本类型,则默认为py,否则,你可以在args中增加<arg name="language">vb</arg>,同样,现在你可以增加<arg name="source">test.py</arg>来从一个文件中运行脚本(source 和script是互斥的)

<?xml version="1.0" encoding="utf-8" ?>
<workflow xmlns="http://www.soho-works.net/workflow">
  <initial-actions>
    <action id="1" name="Start Workflow">
      <pre-functions>
        <function type="scripting">
          <arg name="script">
<![CDATA[

#用来引入assmebly和命名空间
import clr
clr.AddReference("DotNetTools.Core")
clr.AddReference("DotNetTools.PropertySet")
clr.AddReference("DotNetTools.Workflow")
from DotNetTools.Workflow import *
from DotNetTools.Workflow.Basic import *
from System import Console
Console.WriteLine('start workflow')

]]>           
           
          </arg>
        </function>
      </pre-functions>
      <results>
        <unconditional-result old-status="Finished" status="Underway" step="1" owner="${caller}"/>
      </results>
    </action>
  </initial-actions>
  <steps>
    <step id="1" name="First Step">
      <actions>
        <action id="2" name="The first action" auto="true">
          <pre-functions>
            <function type="scripting">
              <arg name="script">
transientVars.Add("test", "this is a test")
              </arg>
            </function>
          </pre-functions>
          <results>
            <result old-status="Finished" status="Queued" step="2">
              <conditions>
                <condition type="scripting">
                  <arg name="script">result=(transientVars["test"]==None)</arg>
                </condition>
              </conditions>
              <pre-functions>
                <function type="scripting">
                  <arg name="script">
Console.WriteLine("From ConditionalResult: "  +  transientVars["test"])
                  </arg>
                </function>
              </pre-functions>
            </result>
            <unconditional-result old-status="NotPassed" status="Queued" step="3">
              <pre-functions>
                <function type="scripting">
                  <arg name="script">
Console.WriteLine(transientVars["test"])
Console.WriteLine('this is lastfunction')
                  </arg>
                </function>
              </pre-functions>
            </unconditional-result>
          </results>
        </action>
      </actions>
    </step>
    <step name="end" id="2"/>
    <step name="end2" id="3"/>
  </steps>
</workflow>

[2007-07-07 20:12:00 | Author:jiangjianxiao ] [] 1 comments

ria 开发乱谈

现在有太多的选择来开发ria程序,传统客户端似乎已经走到了尽头,虽然windows forms有clickonce,java有web start 来解决自动更新问题。但这些都不可避免的锁定到特定的解决方案,特别是windows forms,则显然会将你锁定到windows 平台。

javascript/flash 看来是平台无关的方案,最近在调研ext.js ,看看能否使用在以后的项目中。而silverlight ,不确定在linux平台上的支持情况,看来ms打算让mono团队来做这件事情了,这可能很好,也可能比较糟。好的一面是mono可能会有超常的发挥,糟的一面自然是兼容性和稳定性等。

今天看到 GOA WinForms ,眼前一亮,进而反思自己为什么会对这类东西感兴趣。其实我希望silverlight就像goa winforms的那样,带有大量的windows forms风格的控件,用类似windows forms的方式开发。自己做桌面应用太久了,什么东西都往这上面靠。开发web应用也是如此,用桌面的标准来衡量的话,现在没有一种解决方案能达到vb6/windows forms的控件水准。

其实这个想法同silverlight/flash的设计是不尽相同的,因为silverlight本身就是想要回避windows forms控件的外观,可惜,对于我们数据库开发人员而言,却仅仅关心的是这点,我们希望有大量的控件并接近windows forms控件的外观。有点可笑。我们从来不担心体积,在企业中,搞定这个还不是小菜一碟。

我是应该反思自己的行为,还是去责怪现在解决方案的不健全。现有的方案没有一种是完美的,javascript/windows forms/swing/包括我喜欢的wxpython,都可能挑出一大堆的刺。不过开发还是要继续,目前,我看来只能使用javascript,然后静观silverlight的变化,或者是flash。我隐约的感到,silverlight/flash可能会改变web开发的现状,对于flash,我看来需要花些精力去了解了,不要被设计人员用的东西,肯定不适合开发人员的思维被误导了。

btw:
现在只有一台老机器上装了vs 2005,所以只是测试了goa winforms for flash,大体印象如下
1. 控件表现,特别是outlook panel 印象深刻,这是我最喜欢的控件:)
2.  编译器比较怪异,除了少;会提示外(最近python程序写多的缘故),其他的错误一律没有提示,同vs集成做的还很不好,当然,也没有设计功能。
3. 有些古怪的错误,比方说treeview.AfterSelect+=new EventHandler(...);这里必须是TreeViewEventHandler,当将一个form增加到rightPanel(outlook panel 例子),窗体位置不对,而且浮在panel上方..
4. 这个版本,说是0.2更恰当些。
5. 使用一个.net framework的子集,里面有些类,如System.Net.HttpRequest,System.Net.XmlRequest,System.Net.XmlSocker,应该就是同服务器端交互的主要手段了。没测试具体的通讯方式。
评估版编译的swf每次间隔几分钟后会有个提示,显得比较小气。我个人比较反感伪开源,比方说visual webgui,和伪免费,就像这个东西。有时间再仔细看看,并评估一下silverlight的表现。
[2007-06-25 22:12:45 | Author:jiangjianxiao ] [] 1 comments

正式转入动态语言开发

从5月份开始,我正式使用python,ruby进行项目开发,并将开发环境转到ubuntu 上,现在一个多月过去了,我觉得我可以正式下定决心将全部精力放在动态语言上。主要是cpython和cruby,当然,我会继续跟踪jruby和(ironpython,ironruby,vbx),并真心期待ms能少些平台绑定的东西。

虽然对ruby,python有超过几年的玩票历史,但真正的使用其做项目感觉还是很不同的,这一个月内我有许多感受,并数次想写在blog上,但最后觉得都不成熟。当然,今天写的也是同样,主要有一下几点:
1. linux  像ubuntu 这样的发行版,进入企业领域已经没有问题。接下去,就是应用的问题。开发人员将进一步推动linux在企业中的普及。
2. linux 上有大量的商机。 很多应用,如果由商业公司来完成的话,会做的更好。另外,随着linux平台在企业中应用的展开,将需要更多的linux开发人员。
3. 如果一个公司要从python和ruby中选择一个的话,python更适合。ruby 无疑有太多的magic,只适合高级开发人员,而不是普通开发人员。
4. 应用的速度是个特殊的问题,python和ruby大家一定为认定其速度很慢,结果是不适合开发gui之类的应用,但实际上正相反,python+wxpython,ui的实际反应甚至可以比windows forms更快,我一直认为,速度其实取决于库和应用的层次,像python+c这样,库的速度足够快,层次足够的少,反而能大大弥补语言本身的不足。

早起的鸟儿有虫吃,我正准备成立一个专注于动态语言(python,ruby)开发的公司(确切的时间在明年,因为有太多的事情需要准备),主要原因是觉的动态语言有足够的效率和较好的灵活程度,较宽的适用面,并且缺少竞争(要进入这个领域不容易),而且随着python/ruby的逐渐升温,会有大量的机会。我同好几个网上的朋友讨论过这点,如果你有好的建议,也可以给我留言或发email(jiangjianxiao at gmail.com)给我,我们可以就此进行一些深入的讨论。
[2007-06-18 12:48:47 | Author:jiangjianxiao ] [] 1 comments

小心ipython

由于偷懒,直接使用apt-get 安装了ipython 0.7.3 版本,结果,昨天又被郁闷了,见图,其实在python解释器下是没有问题的,结果又导致我花了几小时去想为什么了xrc文件无法被装载

[IMG]upload/200706060932404125.png[/IMG]


注意:最新的0.81 没有这个问题了
[2007-06-06 09:26:15 | Author:jiangjianxiao ] [] 1 comments

Total 91 Display 26 of 30
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Powered by Google App Engine