C/S架构用wcf data service还是直接连数据库?

whoyousee 2014-11-10 10:45:59
因为是内网程序,不用考虑安全性,我感觉可以直接连数据库。这样好不好?
wcf data service与直接边数据库有什么区别?
...全文
343 12 打赏 收藏 转发到动态 举报
写回复
用AI写文章
12 条回复
切换为时间正序
请发表友善的回复…
发表回复
於黾 2014-11-11
  • 打赏
  • 举报
回复
引用 8 楼 moonwrite 的回复:
app.config中的字符串是加密的 在运行时解密 可否
你根本没理解安全隐患到底出现在哪里,所以拍脑袋想出了这样一个方案 好比我怕邮寄的信件被人偷看 所以我把字典加密了,写字之前再解密,然后用解密后的文字写信,可是这样一来,写的信里还都是汉字啊,别人一样能够偷看
失落的神庙 2014-11-11
  • 打赏
  • 举报
回复
引用 8 楼 moonwrite 的回复:
app.config中的字符串是加密的 在运行时解密 可否
用webservice 吧。
失落的神庙 2014-11-11
  • 打赏
  • 举报
回复
引用 8 楼 moonwrite 的回复:
app.config中的字符串是加密的 在运行时解密 可否
那有什么意义。 相当于脱裤放屁。
mjp1234airen4385 2014-11-11
  • 打赏
  • 举报
回复
对于局域网来说,你明显想的太多了。
江南小鱼 2014-11-10
  • 打赏
  • 举报
回复
引用 楼主 whoyousee 的回复:
因为是内网程序,不用考虑安全性,我感觉可以直接连数据库。这样好不好? wcf data service与直接边数据库有什么区别?
局域网软件,直连数据库问题不大,也就是走两层。 所谓使用wcf做三层架构,不给客户端暴露业务逻辑,wcf服务层直连数据库。
moonwrite 2014-11-10
  • 打赏
  • 举报
回复
app.config中的字符串是加密的 在运行时解密 可否
csjtxy 2014-11-10
  • 打赏
  • 举报
回复
直连效率高,用WCF安全性强。
effun 2014-11-10
  • 打赏
  • 举报
回复
直接访问数据库的方法相对会简单点,但由于没有应用服务器,就没法管理客户端了,有些功能难以实现,比如需要在客户端之间进行同步控制,所以如果应用系统不复杂可以使用数据库直接访问的办法。 WCF不仅仅可以实现数据库的访问,还可以实现更复杂的业务逻辑,可以弥补前面所说的不足,在安全性和系统的可伸缩性方面有很大的优势,如果有足够的资源,还是建议采用这种方式。
mlqxj35674 2014-11-10
  • 打赏
  • 举报
回复
从系统的运行效率上考虑,当然是直连。 从保障机制上考虑,那当然WCF。 个人感觉,最健壮的是WEB Service,跨网络,易于扩展,易于修改,但性能也是要损失一些滴
1987andy 2014-11-10
  • 打赏
  • 举报
回复
如果是内网大多是看个人喜好设计了 可以直接从service连接数据库,也可以中间件,通过wcf访问数据中间件
於黾 2014-11-10
  • 打赏
  • 举报
回复
具体看客户端数量吧 两种方式各有利弊 如果客户端数量很多,客户机器什么版本都有,而数据库又采用的oracle之类的必须安装客户端的,那么还是果断使用中间件吧
winnowc 2014-11-10
  • 打赏
  • 举报
回复
如果功能比较简单,业务上确实没有需要用到service的地方,那就直连好了。 wcf data service直接用起来是方便,不过易于扩展的点不够多,实现复杂功能的代价太大。而且有不少性能损失,提升性能还得做很多事情(json方式、asp.net 输出缓存、iis开启动态压缩等等)。所以如果你不考虑给第三方系统暴露数据,中间层只用wcf data service就没什么必要了。话说微软也抛弃了它,新的方式是使用WebApi + OData,虽然用起来不如wcf data service方便,不过更加灵活。
Microsoft .NET Framework 3.5 Service Pack 1 是一个累积更新,包含很多基于 .NET Framework 2.0、3.0 和 3.5 不断生成的新功能,此外还包括 .NET Framework 2.0 Service Pack 2 和 .NET Framework 3.0 Service Pack 2 累积更新。 .NET Framework 3.5 Service Pack 1 版提供了以下新功能和改进: ASP.NET 动态数据,它提供了丰富的框架,从而使用户可以快速进行数据驱动的开发,而无需编写代码;ASP.NET AJAX 的一项新增功能,对管理浏览器历史记录提供了支持(支持后退按钮)。有关更多信息,请参见 What’s New in ASP.NET and Web Development(ASP.NET 和 Web 开发中的新增功能)。 对公共语言运行时的核心改进包括:改进了 .NET Framework 本机映像的布局、选择不再对完全受信任的程序集进行强名称验证、提高了应用程序启动性能、改进了生成的代码以缩短端对端应用程序执行时间、选择在 ASLR(地址空间布局随机化)模式下运行托管代码(如果操作系统支持)。此外,从网络共享打开的托管应用程序在完全受信任环境下运行时与本机应用程序具有相同的行为。 提高了 Windows Presentation Foundation 的性能,包括缩短了启动时间,提高了与位图效果有关的性能。WPF 的其他新增功能包括:改善了对业务线应用程序、本机初始屏幕、DirectX 像素着色器的支持,并且新增了 WebBrowser 控件。 ClickOnce 应用程序发行者可以决定在适当情况下不进行签名和加密,开发人员可以编程方式安装 ClickOnce 应用程序以显示自定义署名,并且 ClickOnce 错误对话框支持链接到 Web 上应用程序特定的支持网站。 实体框架是从现有的一套 ADO.NET 数据访问技术发展而来的。利用实体框架,开发人员可以按照应用程序特定的域模型(而不是基础数据库模型)来针对关系数据库进行编程。有关更多信息,请参见 Getting Started with the Entity Framework(实体框架入门)。实体框架还引入了一些其他功能,包括支持 SQL Server 2008 的新类型、默认实体图形序列化和实体数据源。在此版本中,实体框架支持 SQL Server 2008 中的新日期和文件流功能。图形序列化工作可帮助开发人员生成将全部图形建模为数据协定的 Windows Communication Foundation (WCF) 服务。实体数据源为希望使用实体框架的 ASP.NET 应用程序构建者提供了传统的数据源体验。 LINQ to SQL 新增了对 SQL Server 2008 中的新日期和文件流功能的支持。 ADO.NET Data Services Framework 由满足以下条件的模式和库组合而成:支持将数据公开为一项基于 REST(具象状态传输)的灵活数据服务,企业网络内部或整个 Internet 上的 Web 客户端都可以使用该服务。ADO.NET Data Services Framework 支持基于任何数据源创建数据服务。通过与 ADO.NET Entity Framework 的充分集成,可以轻松公开基础存储架构的概念视图模型。可以轻松地从任一平台访问使用 ADO.NET Data Services Framework 创建的服务以及兼容的 Windows Live (dev.live.com) 服务。针对运行在 Microsoft 平台上的客户端应用程序提供了一组客户端库,以简化与数据服务的交互。例如,基于 .NET Framework 的客户端可以使用 LINQ 查询数据服务,也可以使用简单的 .NET Framework 对象层更新此服务中的数据。 现在,Windows Communication Foundation 改进了对互操作性的支持,增强了部分受信任情况下的调试体验,并且扩展了整合协议支持以便在 Web 2.0 应用程序中可以进行更广泛的应用,从而使 DataContract 序列化程序变得更易于使用。 用于 SQL Server (SqlClient) 的 .NET Framework 数据提供程序新增了对 SQL Server 2008 中的文件流和稀疏列功能的支持。
项⽬重构⽅案设计 最近接⼿到⼀个已经成型的项⽬,然后我们的任务就是对它进⾏重构,这个项⽬是⼀个功能很齐全的WPF视频播放器(附带很多其他功 能),在仔细研究了项⽬的背景和架构以后,初步做出了⼀下的重构⽅案: ⽬前现状: 虽然整个系统做得很漂亮,代码也写得不错,但仍有以下不⾜: 1. 架构有待改善。虽然看似MVC架构,却没有遵循MVC的模式,⾥⾯逻辑和UI耦合很⾼,没有清晰的规律。 2. 没有充分⽤到WPF的特性。WPF除了给我们很多炫丽的效果外,还给我们提供了诸如Binding,command等特性,这些特性可以帮我们隔开耦合, 同时减少代码量。 3. 代码和⽂件没有组织。代码、dll、样式⽂件和资源⽂件等没有统⼀的组织,到处都有,这样看起来就会很混乱。 4. 没有建⽴公⽤代码库。没有把公⽤的代码库独⽴出来,很多地⽅都是另外在写,这样既增加了代码量,同时维护和重构也带来了⿇烦。 5. 逻辑处理不应暴露在Client端。项⽬是⼀个C/S架构的系统,没有必要把所有的逻辑都暴露在Client端,应该⽤分布式把Logic放在服务器端,这样 可以更安全同时使客户端变⼩。 6. 没有单元测试。这样⼀个庞⼤的程序,没有单元测试是⾮常危险的,我们不可能做到100%的覆盖率,但是我们可以对主要的逻辑和Function做单 元测试,这样既减少了测试⼈员的⼯作量同时整个系统的安全、稳定和可维护性得到了⼤⼤的提⾼。 7. 性能不够优化。启动项⽬,通过WPF性能⼯具Perforator和Visual Profiler分析得出,程序启动和界⾯操作都导致CPU很⾼,内存也消耗⽐较多。 解决⽅案 1. 1. 针对缺陷1的"架构问题"。做法是采⽤MVP或者MVVM模式,⽬前正在对⽐和考虑。 2. 针对缺陷2的"WPF特性"。做法是充分利⽤Binding,command等特性。 3. 针对缺陷3的"代码和⽂件没有组织"。做法是建⽴⼀些单独的⼯程或者⽂件来分类和组织这些代码,并且充分隔离 耦合。 4. 针对缺陷4的"没有建⽴公⽤代码库"。做法是把⼀些公⽤的代码和常⽤的代码做成单独的Dll,并且有完整的单元测 试,这样才能提⾼效率。 5. 针对缺陷5的"逻辑处理不应暴露在Client端"。做法是⽤WCF做为中间层,把业务逻辑全部进⾏封装,通过WCF提 供统⼀的接⼝供项⽬调⽤。 6. 针对缺陷6的"没有单元测试"。做法是不管⽤MVP还是MVVM,我们起码保证对逻辑组件的代码有充分的单元测试 覆盖,同时对⼀些公⽤的组件也要有单独的单元测试代码。 7. 针对缺陷7的"性能不够优化"。这个我会单独做⼀个性能优化列表出来,针对耗资源的操作和其他有损害性能的操 作,我们应该避免。 8. 那么我们就可以结合实际情况搭建如下的结构 9. 10. 因为使⽤了MVVM模式,所以UI结构图就做如下调整 11. 12. 由于整个项⽬客户部希望我们引⽤第三⽅的组件或者⼯具,所以很多功能都只能通过企业库实现,⽐如AOP和 IOC,log和exception对项⽬特征做了定制化,数据访问通过企业库重写实现局部ORM,对性能要求⽐较⾼的应⽤仍 然实现存储过程。对所有事务操作都转移到数据库,邮件使⽤JOB进⾏发送。⼤型数据和客户要求较⾼的实时操 作,⽤MSMQ和SSB相结合的⽅式。层次依赖关系 UI: 功能模块使⽤时候,都会⾸先通过UI层次Security模块的安全验证(验证是通过Components模块⾥⾯的⾃定义的⽤于页⾯功能以及功能 点验证的控件触发), Security模块会通过服务层获取⽤户⾝份数据,⽤于页⾯验证. 功能模块的实际功能实现,如果需要数据库⽀持,那么依然会通过服务层进⾏数据操作.整个架构基于MVVM模式。 Service:通过WCF做中间服务,使应⽤隔离开来,这样有利于扩展和维护,同事提⾼了整个应⽤程序的伸缩性。 Business Logic: 服务层内部之间的组合关系,主要体现再依赖和调⽤,由上往下调⽤,逐级依赖,最后Service底层边界Data Access模块将调 ⽤Framework中的Data模块,Data模块将调⽤MS.EntLib3中的Data,向数据服务器发送数据操作命令和数据. Framework: 该层次提供许多基础的功能模块(七⼤块),分别提供给UI,Service层⾥⾯的模块直接或者间接的调⽤,同时也可以看到 Framework层次内部各模块之间再运⾏时也有互相依赖调⽤的关系存在.该层次的部分模块会依赖和调⽤Ms.EntLib3中的模块,⼀般是按 照两个层次⾥⾯的模块名称,产⽣关系的. MS.EntLib3: 该层次的各个模块是整个系统框架中最底层的,只会在运⾏时被更⾼层次的模块依赖和调⽤,同时该层次内部各个模块之间也 存在依赖和运⾏时调⽤关系.  
项⽬重构⽅案设计 项⽬重构⽅案设计 近期接⼿到⼀个已经成型的项⽬,然后我们的任务就是对它进⾏重构,这个项⽬是⼀个功能⾮常齐全的WPF视频播放器(附带⾮常多其它功能),在细致研究 了项⽬的背景和架构以后,初步做出了⼀下的重构⽅案: 眼下现状: 尽管整个系统做得⾮常美丽,代码也写得不错。但仍有下⾯不⾜: 1. 架构有待改善。 尽管看似MVC架构,却没有遵循MVC的模式。⾥⾯逻辑和UI耦合⾮常⾼,没有清晰的规律。 2. 没有充分⽤到WPF的特性。WPF除了给我们⾮常多炫丽的效果外。还给我们提供了诸如Binding,command等特性,这些特性能够帮我们隔开耦合,同 ⼀时候降低代码量。 3. 代码和⽂件没有组织。代码、dll、样式⽂件和资源⽂件等没有统⼀的组织,到处都有。这样看起来就会⾮常混乱。 4. 没有建⽴公⽤代码库。没有把公⽤的代码库独⽴出来,⾮常多地⽅都是另外在写,这样既添加了代码量,同⼀时候维护和重构也带来了⿇烦。 5. 逻辑处理不应暴露在Client端。项⽬是⼀个C/S架构的系统。没有必要把全部的逻辑都暴露在Client端。应该⽤分布式把Logic放在server端。这样能够更 安全同⼀时候使client变⼩。 6. 没有单元測试。这样⼀个庞⼤的程序,没有单元測试是⾮常危急的。我们不可能做到100%的覆盖率,可是我们能够对基本的逻辑和Function做单元測 试。这样既降低了測试⼈员的⼯作量同⼀时候整个系统的安全、稳定和可维护性得到了⼤⼤的提⾼。 7. 性能不够优化。启动项⽬,通过WPF性能⼯具Perforator和Visual Profiler分析得出,程序启动和界⾯操作都导致CPU⾮常⾼。内存也消耗⽐較多。 解决⽅式 1. 针对缺陷1的"架构问题"。 做法是採⽤MVP或者MVVM模式。眼下正在对照和考虑。 2. 针对缺陷2的"WPF特性"。 做法是充分利⽤Binding,command等特性。 3. 针对缺陷3的"代码和⽂件没有组织"。做法是建⽴⼀些单独的project或者⽂件来分类和组织这些代码,⽽且充分隔离耦合。 4. 针对缺陷4的"没有建⽴公⽤代码库"。 做法是把⼀些公⽤的代码和经常使⽤的代码做成单独的Dll,⽽且有完整的单元測试,这样才⼲提⾼效率。 5. 针对缺陷5的"逻辑处理不应暴露在Client端"。做法是⽤WCF做为中间层。把业务逻辑所有进⾏封装。通过WCF提供统⼀的接⼝供项⽬调⽤。 6. 针对缺陷6的"没有单元測试"。 做法是⽆论⽤MVP还是MVVM,我们起码保证对逻辑组件的代码有充分的单元測试覆盖,同⼀时候对⼀些公⽤的组件也要有单独的单元測试代 码。 7. 针对缺陷7的"性能不够优化"。这个我会单独做⼀个性能优化列表出来,针对耗资源的操作和其它有损害性能的操作,我们应该避免。 8. 那么我们就能够结合实际情况搭建例如以下的结构 9. 10. 由于使⽤了MVVM模式,所以UI结构图就做例如以下调整 11. 12. 由于整个项⽬客户部希望我们引⽤第三⽅的组件或者⼯具。所以⾮常多功能都仅仅能通过企业库实现。⽐⽅AOP和IOC,log和exception对项⽬特 征做了定制化,数据訪问通过企业库重写实现局部ORM,对性能要求⽐較⾼的应⽤仍然实现存储过程。对所有事务操作都转移到数据库。邮件使 ⽤JOB进⾏发送。 ⼤型数据和客户要求较⾼的实时操作。⽤MSMQ和SSB相结合的⽅式。 层次依赖关系 UI: 功能模块使⽤时候,都会⾸先通过UI层次Security模块的安全验证(验证是通过Components模块⾥⾯的⾃⼰定义的⽤于页⾯功能以及功能点验证的控件触 发), Security模块会通过服务层获取⽤户⾝份数据,⽤于页⾯验证. 功能模块的实际功能实现,假设须要数据库⽀持,那么依旧会通过服务层进⾏数据操作.整个架构基于MVVM模式。 Service:通过WCF做中间服务。使应⽤隔离开来,这样有利于扩展和维护。同事提⾼了整个应⽤程序的伸缩性。 Business Logic: 服务层内部之间的组合关系,主要体现再依赖和调⽤,由上往下调⽤,逐级依赖,最后Service底层边界Data Access模块将调⽤Framework中的 Data模块,Data模块将调⽤MS.EntLib3中的Data,向数据server发送数据操作命令和数据. Framework: 该层次提供很多基础的功能模块(七⼤块),分别提供给UI,Service层⾥⾯的模块直接或者间接的调⽤,同⼀时候也能够看到Framework层次内 部各模块之间再执⾏时也有互相依赖调⽤的关系存在.该层次的部分模块会依赖和调⽤Ms.EntLib3中的模块,通常是依照两个层次⾥⾯的模块名称,产⽣关系 的. MS.EntLib3: 该层次的各个模块是整个系统框架中最底层的

110,502

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 C#
社区管理员
  • C#
  • Web++
  • by_封爱
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

让您成为最强悍的C#开发者

试试用AI创作助手写篇文章吧