三人行必有我师,手写三行必有所悟

在使用POCO方式时WCF RIA Service 1.0 For VS2010(版本号4.0.XXX)下，具有实体成员的实体通过:[Invoke]public E GetXXXX()的形式暴露给客户端，是无法编译通过的，这是这个版本的RIA的一个Bug,但这个问题在Sp1版(版本号4.1.xxx)得到了解决。在SP1后，实体嵌套实际上是可以穿越RIA服务的，下面是我测试出来的：1）List等单个

用实体来做事情的时候确实比较方便，有利于编程。但有的时候也非常麻烦，因为有些数据属于属性动态的，这在企业应用中做些比较高级的功能时用的地方比较多，虽然我前面的博文中提供了一种解决方案，但那时后面没有用实体框架，而是直接用可以返回数据集(DataTable,DataSet)的方式进

1、一个依赖对象示例： public class MyDendencyControl : MyDependencyObject    {        public static readonly MyDependencyProperty ContentDepende

依赖属性的好处大家可以参见前面我转载的博文。我们知道，WPF中控件的属性非常多，但这些属性中大部分你在编程过程中是不会改变设置的，而是直接利用其默认值（所以以后设计属性时，默认值的选择也非常关键，这有利于减少存储），如果采用原来的属性方式，每个类的实例都会有自己的一份属性值集合，

下面是依赖对像类的实现：（注，这里涉及到INotifyPropertyChanged接口，大家可以参考MSDN文档了解). ///     /// 依赖对像，主要提供属性值和属性绑定的管理。    ///     public class MyDependency

Silverlight的依赖属性与附加属性SilverlightAttachedProperty,CLR属性,DependancyProperty,Silverlight, 依赖属性, 值变更, 寻值,附加属性好久没写Silverlig

要做ERP这样的企业业务系统，Silverlight+WCF RIA Service还是有欠缺，客户端没有同步调用麻烦多多，服务端的自动生成客户端实体和代理服务代码，是看起来很美，但用处不大，而且极不利于分拆。分几个库吧，公共实体部分生成会重合，会出错，不分吧，都在一起维护很困难

依赖对象一个主要的功能就是提供对依赖属性属性值的管理，所有需要具有依赖属性的类都可以从这里继承，而无需自己去管理依赖属性值。依赖对象的主要方法就是SetValue和GetValue两个方法，这也是依赖属性和普通属性获取值不一样的地方，当然实际的应用中依赖属性一般不会直接使用这两个

今天有空整理了一下Silverlight实战示例（兼集合属性的妙用）系列源码，上传到优快云的下载频道，大家需要的话可以去加载，大家一起进步！如果大家觉得2个资源分贵了，告一声，我回去修改（不知能不能修改资源分？）一下。随便说一声，上载的资源可能需要审核，估计要点时间才能

技术的发展其实都是有迹可寻的.无论多高超，多神秘的技术都是在实践->经验->理论->再实践->...的过程中发展起来的。今天之所以写这个系列的文章，不是为了炫耀我有多牛，当然更不是为了装B，“天外有天，人外有人”的自知自明我还是有的。我的目的其实很简单：       1）对我

依赖对象准备增加了属性元数据类型的定义，开始忘记贴了。以上代码都经过了测试，模拟是成功的。其实微软在页面中的绑定语法最终都会如模拟中那样实现。微软的做法是导入xaml文件的时候根据文件中的控件语法动态的生成控件实例，其绑定语法也是在这个过程中自动添加进出的，只不过需要一个简单的路

1）对于Entity的支持相对来说比较好，自动生成的实体如果以Entity为基类，可以挂接属性改变事件，这个非常有用，但如果生成的实体以ComplexObject为基类，则没有这个好处；2）ComplextObject对于服务端得实体要求不是很严，不像要生成Entity为基类

1、确实没有服务方法；2、Web.Config中没有相应的DomainService配置（解决：在承载应用添加一个空的域服务，然后删除即可）；3、服务方法是在于一个WCF RIA Services类库里，如果承载网站没有引用，或者是如果承载网站下Bin里的dll没有更新也会提示这种错误（VS的自动复制有的时候不是非常有效）；（解决：同步更新相应的dll文件到bin目录下)4、服务方法没有打Invo

其实这个控件的技术含量还是有的，至少包含了以下知识点：1）窗口及控件定位及布局      因为里面牵扯到窗口的拖动，大小的调整等。2）模板化控件开发；3）窗口的最大化、最小化处理；4）鼠标事件的处理；5)  窗口的坐标及坐标平移;6) 模态窗口和非模态窗口的状态及管理，窗口之间的关系维护等。本来打算写一个系列的博文来讲解这种控件的开发，后面觉得没必要，整多了，也

这个系列主要针对的是Silverlight相关的编程技术，探讨层次比较深入，这里整理了一下，方便大家阅读：WPF架构关键技术剖析(1)--序言WPF架构关键技术剖析(2)--XAML、对象序列化、类动态实例化WPF架构关键技术剖析(3)--做自己的交互Action(1

现在的silverlight客户端绑定支持索引器方式，比如VM有属性:public Dictionary KeyValues{get;set;}在后台CS中我们要访问某个key的值的方式是:KeyValues["XXXX"],其中XXXX是key.而在xaml中可以如下访

今天比较深入的接触了一下VS的MVC开发，有点感触，所以写点感言。因为接触不是很久，研究不够深入，写这些主要是测试一下自己的技术敏感度，如果下次发现自己写得不对，其实也是一种提高，所以大家看的时候，就当娱乐吧。我们首先来看看MVC和WebForm:1）首先MVC和webF

控件放在我的资源里面.这个控件是一个窗口控件，可用于Silverlight的MDI开发，既可以作为MDI的子窗体，又可作为模态窗体使用，但这种模态只针对父窗体，比如MDI窗体中有在A，B两个子窗体，A窗体弹出模态窗体C，只会禁用A窗体，不会影响B窗体。看过老外发布的类似控件，感觉

在前面的博文中，如果要能进行修改，都是用strValue进行绑定的，但这只说明string类型的在datagrid自动生成的列中是可以编辑的，用Object进行绑定一样也可以编辑，但需要进行一定的处理，而且用strvalue,intvalue分别绑定也不符合开发友好原则，我在示例

这里是部分代码，其它代码见Silverlight实战示例，直接上代码：1）DynamicDataField.cs    [Serializable]    public partial class DynamicDataField    {        pu

因为字典都来自统一的字典表，访问方式基本相同，利用绑定可以支持索引的特性，搞了一个通用的字典数据源加载的机制，程序员使用的时候非常方便，可以提供给下拉框，列表框等地方。统一的绑定访问的形式:{binding Path=Dict[XXXX].DictValues},dict属性放在

下面我们利用附加属性，将我们准备好的Action集合能作为附加属性出现在xaml中：1）附加属性类：///     /// 附加属性定义类，注意必须是静态的，这有点类似于给类增加扩展方法。    ///     public static class WPFT

1）视图层后台代码，很简洁，主要是处理视图模型的创建，当然，如果你利用一些技术，这里是可以不需要代码的。不过我的观点是任何事情都不要搞成洁癖，如果页面的所有控制都放在视图模型层，反而会使得视图模型层最后就变成了视图的后台代码，那么这个MVVM模式就失去了意义。using ME

这两层实际上就是大多数实体框架所处的层次，在这两个层次方面，大家可以参考动软的方式，当然，也可以自己构建，也可以利用现有的成熟的实体框架。但对于大型项目或者产品型项目，最好还是不要使用那些复杂的实体框架，因为更新，维护，升级都不太可控，而且很多时候都会有一些限制，不太利于构建高效

我们知道对于界面元素的描述，WPF的XAML不是第一个，HTML就要早很多，delphi的dfm也是一种。界面描述和界面交互逻辑的分离是有很多好处的，比如有利于可视化设计，有利于界面复用等。微软总是想一统天下，WPF的出现也是这种理想。当然，这种理想的出现也是有实际需求支持的。对

Silverlight走的是富客户端路线(RIA)，与之紧密结合的是WFC RIA,由它来负责与服务器端得通信（WebService虽然也可以，但开发难度和工作量都比较大）。这为稍微复杂的Web程序改善用户体验提供了好处，如果纯粹作为普通的在线应用，应该说还是够的，但对于一些较为

经过1个月的学习，从接触Silverlight到现在完成一个初具企业级应用框架的实现，确实感觉比较累。本来底层定型很快，但由于选型时争论比较长，拖了点时间，而我本来只负责底层，但由于客户端小组进展比较慢（原因一言难尽），这个星期我开始接手这方面的工作，经过几天的努力，在UI组兄弟

M是模型层，实际上就是客户端得数据服务层，而V是页面，即视图层，VM是视图的模型层，也可以看做是M和V之间的桥接层。我们知道在数据库编程中，特别是Delphi中的数据库编程中，数据感知控件一定令人印象深刻：界面控件只要设置一个数据源(DataSource)，然后设定本控件要绑

Imagine you want to enumerate (enlist) all rows (DataGridRow) of Silverlight Grid (DataGrid). By design this is not very simple tasks.Fo

Domainservice不支持泛型，WFC RIA传到客户端又不支持继承，这下省了搞Services基类，程序员能做的事情变多了，一个个手工搞，有需求，有工作其实是皆大欢喜，这下要谢谢微软了。其实微软还是挺能为其他人着想，微软的操作系统既让做硬盘的发财，也让做CPU

至少在目前为止，经过测试，我发现一个实体A引用了另外一个实体成员B，如果另外一个成员B又引用实体成员A，如果A为null，没问题，如果A不为空，与B形成实例上的循环引用，就会导致客户端访问提示找不到调用方法的错误，我觉得应该是这个循环引用导致返回客户端时进行序列化时，导致无限循环

最近在做权限访问的封装，我们的权限分为用户(角色)，对象，操作，行级4个层次。在权限数据方面，我们的处理方式是一次性获取相关权限数据（SQL比较复杂一点），并按对象，操作，行级组织成层次结构，然后对这部分数据进行了缓存，而且是客户端和服务器端同时缓存，这样做虽然便于用户权限访问方

在前面的Silverlight实战示例7（兼集合属性的妙用)系列中，我们模拟了一个复杂实体的处理，这个复杂实体类似于aspnet的Datatable，但不是很完全，这里我们增加一些代码，使得这种模拟更纯粹：1、在DynamicDataField里增加public Dynami

对于一般程序语言,执行分为3种:1)编译成二进制机器代码,由操作系统调用执行;典型的如C,C++,Delphi等.2)编译成中间语言,由虚拟机解释来执行或及时编译后执行(前者的典型是java,后者的典型是DotNet).3)不进行编译,有解释器边解释边执行,比较典型的

Silverlight4的属性绑定支持索引器，利用这个特性就可以实现VM对V提供更为方便的支持，而且对于基本类型的字典还可以穿越WFC RIA服务，对于DataTable之类的动态数据，就可以利用这个特性不仅可以穿越服务，还可以动态绑定到Silverlight客户端.动态实体

在本篇中，我们不仅演示实体的结构，而且我们利用集合属性来打造万能实体（类似于DataTable)。 下面是代码：1）首先我们定义Column,主要提供字段列信息：DynamicDataColumn.csusing System;using System.Collect

结合这个系列博文，加上我前面的对依赖属性模拟的博文，如果大家仔细看过，应该收获很大，可以讲Silverlight的页面交互机制应该是非常的清楚了，而这篇博文的Action实现，其实就是一个简易的交互框架。Silverlight本身提供的Triggers,Behaviors也是这个

本来打算写得细些，但最近要换工作，所以比较忙点，而且也觉得没必要写那么多虚的东西，因此这里不再按照提纲进行，而是从代码入手，看清Silverlight的交互机制.依赖属性和附加属性的基本类都是一样的，但依赖属性和附加属性的用途还是有区别的，依赖属性更多的是属性，而附加属性更多的是

1)测试数据准备：//这是我学习treeview绑定时用的，也随带给不是很会用treeview绑定的网友们一个例子.A)层级类，树形结构.public class Folder    {        public ObservableCollection C

3)视图模型层DynamicDataViewModel .csusing System;using System.Net;using System.Windows;using System.Windows.Controls;using System.Windo