WPF版的权限管理系统

好多技术人员都有一个通病，不关注用户的需求，产品的可用性，只看使用的技术的新不新，潮不潮，这就是所谓的技术发烧友。

这段时间，断断续续的开发一个WPF的软件，也拿出来Show一下。要不放在硬盘里就发霉了。

热点一：SOA的分布式理念

　　现在的开发理念，不管是企业级的ERP，还是网站式的应用，都涉及到了SOA的分布式。就拿一个比较典型的网站来说吧，做网站的童鞋们对CAS，SSO这些关键字并不陌生吧，实质就是应用了SOA的理念，把一个网站平台的认证授权单独抽取出来独立成一个系统，其它业务网站的认证授权都以这个为基础，实现了单点的登录，授权。其实在企业级的ERP中，我们也是这么干的，我们把认证授权提取成一个独立的基础平台（这个甚而平台有可能包括：公共基础数据系统，消息系统，工作流，报表）的一个子系统，其它业务系统都围绕着这个基础平台进行开发。如下图所示，把每个业务系统的权限都提取出来，放在基础平台。

因为这是一个基础开发平台，所以必须为别的应用程序留下服务接口，方便的与别的应用程序通信，实现其软件的价值。

热点二：WCF的安全机制（拦截器）

我们把通用的功能都提取出来组成了一个基础开发平台，以后的业务系统都只关心业务固然是好。不过有点乌托邦了。你想想，业务系统与基础系统怎样通信？怎和样保证通信的安全，这个问题曾经困扰了我好久。系统之间的通信，大家不约而同的可能都想到了Web Service或者WCF吧，不过怎样保证Web Service,WCF的安全呢？我还看到过有人用javascript来调用web Service（Web Service做的是CRUD的操作），这是把自己的衣服脱了赤裸裸的让别人来攻击，给我吓出了一身冷汗呀！

那我们怎样来保证Web Service 或者WCF的安全呢？最笨的方法可以为每个WCF或者Web Service定义两个参数（一个用户名，一个加密码的密码）， 或者再改进一下定义一个Token的参数（这个方法我这样做过，鄙视自己一下），有的为了代码看起来更优雅一些，在请求服务时把这个Token写在Header里。然后在执行Web Service 或者  WCF的主体之前，根据传过来的参数在数据库里查询一下，判断这个请求是否有权限。不过一些中大型的系统，一般都会有上百甚至几千个Web Service，每个服务都定义一个参数，或者在Header里定义一个键值对，是不是显得代码很臃肿呢？我们针对这样的问题，我们采用WCF特别的机制拦截器。 WCF中的拦截器其实就是AOP的一个实现，当然这个实现我们也可以自己来写。

在调用每个Web Service或者WCF之前，我都加一个Token在Header里，这个动作，我们完全可以公用，就是采用AOP技术。

在公共基础平台接收到请求的时候，同样可以用AOP的技术，判断Token是否有效。具全实现看源码。

热点三：WPF

在bs结构的系统中，HTML5的UI比较有前景，在cs结构的UI中，我想WPF应该有她独特的优势，在这儿我们暂时不讨论平台的好坏，技术优劣。且看我怎样用WPF来实现一个软件的UI。

1)个性化的菜单：

2）炫耀的表单验证

3）自定义，动态生成xaml的模板

4）目前正在用mvvmlight改写原有的代码。

这些亮点都不得不让我用WPF，这是一个技术爱好者的执着追求，是我的理念。

热点四：Code First

我们什么SOA, AOP, IOC等热点技术都用上了，千万不要拉下了ORM，ORM有Ibatis, hibernate,daper等，但是从性能，可使用性上来说各有千秋，没有优劣，但是我感觉在.net平台上，只有entity framework才是真正的可用orm。entity framework有三种模式，mode first, database first, code first。我为什么在这个项目中选择code first是有原因的。因为我定义的实体，既想作为生成数据库的定义，又想作为WCF中数据传输的数据契约。往往单方面从一个技术角度来看并不难，但是技术与技术叠加，就会出现很多稀奇的问题。我上一段代码片段：

其中红色的是WCF数据契约的标识，蓝色的是Code First的数据定义。把这两种定义都集中在Model上，减少了业务层代码，业务层重点放在了处理业务上。

总结：

此软件在用户操作体验，代码结构上都有待改进的地方，在上文的介绍中，你对某个东西感兴趣可以在博客园发短消息联系我，一起探讨，共同进步。

如果想获取源码，可以请我喝一杯，毕竟辛苦了好久，支持我一下。^_^  源码下载