Car*_*erg 18 architecture asp.net-mvc wcf n-tier-architecture odata
我们主要开发低流量但高度专业化的Web应用程序.通常我们使用L2S,EF或nHibernate作为访问层,然后将Asp.Net MVC抛给它,在正常的crud操作中我们直接查询ISession/DataContext但是对于更高级的函数/副作用我们把它放在某种类型的服务层.
现在,我考虑通过OData(WCF数据服务)发布数据并从控制器查询(甚至在良好的模板引擎显示时从jQuery中查询)并通过WCF服务发布服务操作(或作为自定义方法)在WCF数据服务？).这种架构有哪些优点/缺点？
除了更高的复杂性和延迟,我能获得一些东西 更好地分离关注点(或者只是一种错觉)？
编辑: 用例如创建一个完整的ajax驱动的解决方案是一个好主意.WCF RIA服务？或者做一个松散太多的灵活性？感觉像你可以从你的逻辑中完全发送你的观点,那么,一个应该能够只写纯HTML,甚至不需要asp.net MVC？但我想有很多新问题出现了？
小智 32
不要这样做.对不起,这是一种愚蠢的过度设计方法.你是一个进程,你坚持运行网络连接和编码所有传递数据到XML并退出,加上在有限查询语义的HTTP连接上运行它？不要告诉任何人你甚至尝试过.
关注点分离是一种错觉 - 您使用简化的数据层替换高度优化的域模型.
这就是说:我喜欢OData - 很棒.但它不是程序技术,它是一种FRONT END技术,就像ASP.NET MVC一样 - 只是不是针对最终用户,而是针对另一个程序集成到您的数据中.它应该在类似的场景中使用,并且当通过信任边界公开数据时(例如,Silverlight是信任边界,因为请求可以伪造).
它没有经过优化,可以替换像NHibernate这样的高端应用程序运行时层.
Pab*_*tro 20
正如TomTom所提到的,您不希望在进程内为OData支付环回成本.如果您对数据库有直接的视线,并且它是您自己的应用程序的数据库,则没有理由将WCF数据服务放在中间.我会继续使用你提到的其他选项之一(L2S,EF,nHibernate).
现在,如果您需要通过http端点公开数据以供其他应用程序使用,或者甚至是您自己的应用程序,如果客户端中有一些需要从服务器访问数据的jQuery代码,那么OData端点肯定会有所帮助, WCF数据服务是创建一个最简单的方法.
| 归档时间： |
|
| 查看次数： |
5661 次 |
| 最近记录： |