玩.net的， 讨论下VS2010的新功能

happysee

原帖由 flyspirit 于 2010-5-21 22:04 发表


不认为business logic放在sp里面是个好主意，如果business logic复杂，sp开发维护起来很困难。

复杂的SP可以用CLR来写。

flyspirit

原帖由 happysee 于 2010-5-21 23:38 发表

复杂的SP可以用CLR来写。

你说得对。但是怎么解决scalability的问题？如果business logic在部署在中间层可以单独扩展。

乱码

原帖由 flyspirit 于 2010-5-21 22:04 发表


不认为business logic放在sp里面是个好主意，如果business logic复杂，sp开发维护起来很困难。

我们team还行，大家一开始不适应，很多人用sp就是crud,后来慢慢适应了，.net developer需要些sql query方面的trainning的。

typical scenario的trainning+detailed comments是我们的主要手段。

[ 本帖最后由 乱码 于 2010-5-24 09:46 编辑 ]

乱码

原帖由 happysee 于 2010-5-21 23:38 发表

复杂的SP可以用CLR来写。

我们把.net在database的应用作为nice helper，95%的coding还是用sql来做。

dalaohu

Topic is too border. U need specific cases.

Both side are correct. Both side can be wrong.

Just like compare webform vs mvc. There's no winners.

Hving said all that. I'm leaning towards logic in mid tier

better scalability. Extensibility. Deployment.  Unit test friendly. Strong language tooling support. Easier to maintain.

But certainly SQL has Lots logic process aswell other than crud.
It's a thin line between them

flyspirit

原帖由 乱码 于 2010-5-24 09:42 发表


我们team还行，大家一开始不适应，很多人用sp就是crud,后来慢慢适应了，.net developer需要些sql query方面的trainning的。

typical scenario的trainning+detailed comments是我们的主要手段。

你们这么做应该也有你们的道理，或者有可能是status quo, 因为一直这样做，所以就做下去了。但不一定是best practice.

如果有新项目或者跳槽接触新东西，还是先考虑采用业界推荐的开发模式更好些。

乱码

原帖由 flyspirit 于 2010-5-25 11:09 发表


你们这么做应该也有你们的道理，或者有可能是status quo, 因为一直这样做，所以就做下去了。但不一定是best practice.

如果有新项目或者跳槽接触新东西，还是先考虑采用业界推荐的开发模式更好些。

这主要是基于performance考虑的，
1。app server很忙，business logic 放在db side，可以有效的减轻app server的负担。
2。我们push大量的client side logic to browser side using JS/jquery，避免postback,为了避免code duplication（js version vs. c# version)，ajax call也可以用,可能维护js/jquery也能让.net developer头疼一阵的。
3。从维护的角度来看，即使我们的business logic 用c#在app server实现，也绝对不好维护，可能从逻辑上说对.net developer更容易理解些，但损失的performance不是一点半点。
4。我们team member还好，pick up t-sql不算慢，但我们有decicated人来做这个，一般是我自己，browser side的js/jquery就看个人了。

flyspirit

关于第1点，App Server本来用于Business logic的，现在都移到db side了，app server为什么会忙？

3。performance是有损失，但通过优化可以弥补，而且很多情况下performance的损失并不critical，通常情况下只需要优化20%关键代码就可以得到80%的性能提高。何况有些business logic，比如大量计算，在App server内存里要比在db快吧。

说到性能，业界不泛高性能，n-tier/n-layer的系统，BL在app server并不成为瓶颈，这点大可不必顾虑。

dalaohu

So boring. Should we change topic?

乱码

原帖由 flyspirit 于 2010-5-25 13:06 发表
关于第1点，App Server本来用于Business logic的，现在都移到db side了，app server为什么会忙？

3。performance是有损失，但通过优化可以弥补，而且很多情况下performance的损失并不critical，通常情况下只需要优 ...

flyspirit,good question!!

1. 我们网站的order每天5k以上，总价值在300k au dollar（折算过来）,单纯的browser我们都不统计了。 我们定义app server的功能 1。run IIS 2。接受request和pass data back and force.
   把所有的复杂运算和report的logic放在db side, 最近的一个report，我有14个cte在连用，这也是我写过得最复杂的一个sp（调起来都很费劲，还得放到temp table里调）。这种运算如果放在app server side,对我们来说基本上算是自杀了。

2.performance的要求对我们来说超过maintainance的需要,我们对developer要求也很高的，从我现在来看，我们设计初期data modeling的阶段出了一个很致命的flaw,导致整个系统一直performance上不来。
app server的运算性能比db那边低不少，尤其是对collection query的操作, c#对collection的操作类似于t-sql的cursor（用到linq会好很多，这是另外一个话题了），而db那边是set的操作，如果再加上trafic和round trip call,performance就基本上不是一个级别的。n-tier的design只能说让其scalibility大幅提高，要真正较真的话，对性能来说是降低，毕竟是cross dll call,不过这些都可以忽略的。为什么还有的公司stick on classic asp,而不转到.net,基本上和我们考虑差不多的。

[ 本帖最后由 乱码 于 2010-5-25 13:45 编辑 ]

dalaohu

Sounds like u dealing with badly designed db big time

乱码

原帖由 dalaohu 于 2010-5-25 13:44 发表
Sounds like u dealing with badly designed db big time

这个design flaw我提过N次了，我们公司到现在一直没有机会纠正，原因是：
1。office politics.
2. budget issue.

不过对我来说现在没所谓，我都hand over了,混混日子就走了。

dalaohu

I'm sure u did the right thing for the tech situation ur in

u don't want make 100 db calls from UI  to get one job done

乱码

原帖由 dalaohu 于 2010-5-25 13:54 发表
I'm sure u did the right thing for the tech situation ur in

u don't want make 100 db calls from UI  to get one job done

thx mate :)  
that's one of the reasons we have been extremely cautious about linq to sql.

flyspirit

知道你们采用现有的解决方案有自己的道理。

跳出你们的现有环境，在一个比较common的senario下讨论Business Logic应该在App Server还是Database。App Server的优点是

1。 .NET有可以支持Set的数据结构，并不是所有操作都需要query list。
2。 App Server中的business logic不需要每次都访问DB, 一个HTTP call里面可以有cache或者局部变量保存之前得到的数据。
3。对于全局数据可以放在全局cache中。
4。扩展性，扩展性本身就是牺牲局部性能获得全局性能，一台server慢点没有关系，加机器就行了，App Server的扩展要比db server方便很多。
5。可以用多线程，现在普通机器都有2核，服务器8核很普通，开多线程可以充分利用这些Core。 .NET 4.0可以更方便的实现多线程。
6。功能虫用，和维护性这些。

flyspirit

对于实在需要放在DB处理的，可以写SP并在APP Server中调用。

乱码

good points flyspirit!!

1.".NET有可以支持Set的数据结构，并不是所有操作都需要query list。" --- can u elaborate?
2.我们的确有cache的data, 不过只是用来display, 而不是用来caculation.
3. 我们有load balancer和两台live app server 来处理request,目前来看效果还不错。
4。关于multi-threading,我们基本上不太会走这个方向，最重要的原因就是multi_threading如果出现bug，将会是非常tricky的bug,很难reproduce，我们不会去冒这个险。

flyspirit

1. HashSet<T> can be used to gain high performance
2. 你是指Page Cache吧，还可以做Object Cache。如果简单点，Page Level的varaible也可以做到cache功能。
3。你说的app server，我会叫它Web Server，app server是跑service的，比如web service或者WCF service, 我的结构是web server(IIS)+appserver(BL service)+DB server(data), 三层都可扩展，但web server扩展最简单，app server其次，最难是db。 你的结构里是web server+db server， db server里面跑logic，同时存储数据，
4。在.NET 4.0引进了parallel computing和parallel LINQ, 使 mutli-threading非常容易。

乱码

flyspirit, u keep throwing brilliant ideas, you are the man!!

1. Hashset is new to me, it's good to know.不过有了linq to object,这种data struct意义大么？而且它不可以通过[]access。
2. 我们cache 多种东西，page, objects...
3. 你们的app server (hosting service)为什么跟web server 分开？是两个box么？这样做的原因是什么？
4. 我可能应该好好看看parallel computing,但这个project应该用不上了。

[ 本帖最后由 乱码 于 2010-5-25 17:51 编辑 ]

starchu

附加一点深入的知识，对分布式计算感兴趣的可以在PLinq的基础上，看看DryadLINQ, 支持large-scale data parallel applications running on large PC clusters。 概念类似于google map reduce, 我知道的NASA火星探索计划实验小组成员，专门和微软合作用它来做火星表面成像分析。如果想在微软平台上做map reduce类似的应用，可以尝试. 初次见到他们的Task Parallel Library (TPL)，是07年底，微软负责分布式计算的一个architect到我们那里来宣传，API很简单，没想到这么久才正式加入.NET 4.0, 不过确实是一个不错的方法。唯一的问题是他们的性能，对小量集群的性能比较好，对大规模的集群计算在性能上有待验证

[ 本帖最后由 starchu 于 2010-5-25 22:19 编辑 ]

starchu

大家还可以尝试微软Azure, 毕竟cloud computing是微软未来的主攻方向。

flyspirit

不客气，探讨探讨，App Server的部署主要基于这几个原因：

1。扩展，Web server, App Server可以使各个tier自由扩展。有时候瓶颈不是在BL层，可能仅仅是由于http request太多，但每个request没有什么复杂逻辑，这样只要单独扩展Web server就可以。
2。安全，app server不用直接对外，而且app server和Web Server间可以做些安全措施。
3。共享，多个request可以在一个app server的一个进程中并发处理，可以一定程度共享资源。
4。复用，app server可以不仅被web server使用，还可以被企业内部使用，比如报表，管理。或者是多种展示方式，比如web, windows app, smart phone 等不同客户端都可以访问通一个app server，在bl层的逻辑是统一的。
5。还可以让appserver的service接口给第三方使用，比如其他部门，其他公司。google以及主流socail website比如twitter都提供service接口。企业级应用也有，比如salesforce.

flyspirit

原帖由 starchu 于 2010-5-25 22:11 发表
附加一点深入的知识，对分布式计算感兴趣的可以在PLinq的基础上，看看DryadLINQ, 支持large-scale data parallel applications running on large PC clusters。 概念类似于google map reduce, 我知道的NASA火星探索计 ...

你是指.net的Parellel方案在大规模集群上还没验证过？

[ 本帖最后由 flyspirit 于 2010-5-25 22:32 编辑 ]

flyspirit

原帖由 starchu 于 2010-5-25 22:21 发表
大家还可以尝试微软Azure, 毕竟cloud computing是微软未来的主攻方向。

不光是微软，其他巨头也在搞这个。

有Azure的经验吗？我是没做过。

starchu

原帖由 flyspirit 于 2010-5-25 22:28 发表


你是指.net的Parellel方案在大规模集群上还没验证过？

微软没有在大规模上验证过，微软的分布式研发能力本来就比较弱，之前没有专门搞这些，和他们的商业模式不和，近两年才迎头赶上的，特别是cloud 热了之后。

starchu

原帖由 flyspirit 于 2010-5-25 22:31 发表


不光是微软，其他巨头也在搞这个。

有Azure的经验吗？我是没做过。

目前提供云计算开发平台的主要是微软azure, google app engine还有salesforce的force.com, 除了force.com没有搞过，前两个都搞了搞，呵呵。 每个巨头的cloud专注方向不同，有些专注private cloud,比如IBM,有些专注于提供基础设施，比如amazon, 还有些专注于硬件和网络设备，比如cisco. 主要用于开发的只有微软，google,和force.com

[ 本帖最后由 starchu 于 2010-5-25 22:45 编辑 ]

flyspirit

原帖由 starchu 于 2010-5-25 22:42 发表


目前提供云计算开发平台的主要是微软azure, google app engine还有salesforce的force.com, 除了force.com没有搞过，前两个都搞了搞，呵呵。 每个巨头的cloud专注方向不同，有些专注private cloud,比如IBM,有些专 ...

能不能说说在Azure平台上开发的应用能有什么优势？和传统开发有什么不同处？

starchu

原帖由 flyspirit 于 2010-5-25 23:12 发表


能不能说说在Azure平台上开发的应用能有什么优势？和传统开发有什么不同处？

简单的说，云计算解决的是web应用程序的一个基本问题scalability, 其他的特性比如pay as you go, 并不是它的技术优势，而是它的商业盈利模式。所以云计算的最主要目的是解决scalability. 一个应用怎么样做到scalable。 在Azure上开发的web应用，使用Azure专有的一些服务，开发程序不用考虑发布的问题，不用考虑怎么样配置服务器的问题，因为你开发的应用都将自动通过Azure提供的VS plugin自动发布到微软的数据中心里面。并且保证了你的大负载处理能力，而且是按照你的用户使用量来收费。

举个例子，一个类似facebook的应用，如果使用传统方式开发，你需要考虑很多问题，比如怎么样有效的处理数据层的操作，怎么样处理用户session数据，才能做到scalable, 同时你需要手动配置load balancer, 和数台服务器来实现大量用户访问时的负载均衡。当时不管你怎么优化，你的处理容量还是跟你硬件性能和能力成正比，只有不断的加大硬件的投入，你才能服务更多的客户。

同样的应用你用Azure开发，数据层的各种关于scalability的优化你都可以不用考虑那么深了，因为Azure提供的服务保证了它们的服务是非常scalable的。同时你不需要担心应用发布问题，它帮你自动发布到微软的私有数据中心，它将智能的根据你的当前用户访问量分配足够使用的虚拟服务器来提供super scalability. 你将不在需要手动添加任何硬件，只需要按照使用量支付虚拟服务的费用。更大的一个优势是，应用可以做到local aware, 如果你的用户是来自中国，Azure在中国配有数据中心的花，用户访问的将是在中国的虚拟机，保证了最高效的速度。

这些例子只是使用云计算开发相对于传统开发的一些基本好处，其实云计算是一种商业模式的变革，以安装为基础的很多传统软件将不在流行，可能不久的将来，你的数据，计算和各类应用都将在其他的数据中心里面，你不在需要买软件，只需要租用软件，你只需要一个browser就可以完成所有的工作，同时访问的性能将不会因为无数的用户同时访问而产生不好的效果，这就是cloud的魔力。 google的chrome操作系统就是一个很好的例子，未来的操作系统就是那个样子。当然这还用很长的路要走，很多问题都需要解决，比如安全，比如政府的法律约束等等。

flyspirit

谢谢写了这么多。

Azure有时间一定要研究一下。

flyspirit

请推荐下你觉得好的入门资料， Azure和DryadLINQ