@ljk
既然出来只要他走完这110就OK了...
如果是一个真正的运动员他会这样干,如果是一个演员估计更加会这样干...
做人不容易啊.

模式只是方法并不是定理,她没并不能保证什么;因为程序的好坏取决于开发人员.
如同楼主的代码一样,虽然你用了模式但显然你不能保证那段代码是最好最有说服力的:)不要顾此失彼.
一个好的程序永远都会关注已经完成的东西是不是有更好的方法去代替.

@Gray Zhang
这样插爽的...不用建了模型后又要手动去搞数据库...

我想知道EDM是否支持正向工程？

@hrmai
第一情况的Create是描述方法的定义如何降低方法约定变更的风险.
第二情况的Create是表达两中情况在User发生变化后,各自内部的调整情况.

@Ivony...
这倒不是我面对问题.
只是举个情况,设计往往是要面对不可知的情况,既然是不知道我们就不可能去假设.即使是有些东西是可以假设,但也应该有个度(这就完全取决于设计人员的经验)
所以设计越简单越好(不过这个简单其实并不简单,就如你前面提到的要清楚,其实并不容易)

@Ivony...
我个人认为没有优秀的设计,也很难假设能有多少变更;
其实有很多是凭经验的,如DAL的设计那样可能没有这方面经验的人员(也许这人没有从事过这方面设计),可能没有考虑到事务协同的问题.但紧紧凭这一点就把这个设计否决是不现实现;如果设计人员在面对这情况下很快就调整过来那这也算是个好的设计.
设计能对不可知道的情况可以进行快速调整的设计才是好的设计.
如果我们什么情况都能了解就更好了:)

@wb

其实设计比较讲经验,问题是如何总结经验.个人比较认同重构,我也一直这样干.虽然项目中重构的机会不多,但很多时候可以把问题拿到项目外在有时间的情况下重构.

@Ivony...
是的:)在login的描述是很荒谬,只是说明方法约定的设计也是要有技巧.

又是一个看书然后搬出来...
什么时候应该用继承,什么时候应该用委托才是重要;
而这里根本体现不出优越性,反而比继承多写了代码.
楼主还是做一个体现情况的例子吧,如怎样继承导致代码不好维护和扩展,这时选用委托更适合.

http://www.dynarch.com/projects/calendar/
多样式,多国语言包,键选择支持等功能.有好用的就不要自己写得这么辛苦了:)
如果想学习可以参考一下这个

对技术人员来说当前的设计方法好还是坏并不重要，重要的是能不断探索更好的设计方案就可以了。

@金色海洋（jyk）
其实说真的我们想不到的事情有很多的,既然是业务逻辑就存在很多不可知的因素.这些因素情况多到不可想象（因为业务的变化会产生不可知的因素）,如在前、在后或中间添中一些变更逻辑...然后在这基础上再做变更...
中间某些环节锁处理，事务整合等；因此逻辑最好是一个完全体...对于事件最多只能当担验证、日志等处理逻辑以外的功能。

员工一个类.
然后有考核的房间,职位补贴房间,业务考核房间...
员工进去房间是拿钱还是扣钱那就是房间的事情,毕竟别人的地盘别人做主.

@在路上的牛
是的,所以设计者不能执著,因为以后要面多怎样的情况没有知道.
我们设计的时候也不要太执著于什么方式或模式,简单修改维护的代码就是好设计

@Teddy's Knowledge Base
我也认为是设计过度了.重新组合显然对于修改和扩展都很方便.
然而这种aop倒会使维护和以后扩展增加风险.

@zd.cgh@163.com
抱歉,暂时无法满足你的要求.

@zdcgh
对现有版本的LINQ TO SQL感觉不理想（只是个人看法），不知道EF能带新的改变。我想看的是LINQ TO SQL各个部分都能独立和相互组合。
如条件，获取数据，对象关联描述等等。
我还是看好LINQ，因为MS可以在编译器做很多约束、验证等功能支持。

还是搞个VM来装吧。。。
必要是snapshot一下

建个二维数组,一次性把数组填补到相关区域效率快N倍
给一个东西你看适不适合你
http://www.cnblogs.com/henryfan/archive/2006/01/22/321653.html

@zdcgh
是的,和HFSoft.Data一样.
有点意外你对这东西感兴趣:)

...这根本不是并发的问题(应该是数据冲突).是用户在不同时间里进行的数据操作,只是其编辑前的数据不是最新的.
记录加个版本标记,获取数据里的标记在保存时判断一下是否想同.如果不一样程序提示不保存就是了

asp+com（业务组件）的方式估计很少用，相互调试性也很差。
新平台下带给我们的是开发效率上一个等级的提高，虽然编写方式有点相似。
其实aspx下可以完全把所有事情干完，为什么还要把功能独立拆分进行整合呢？为什么这样干才是值得我们深思。

是可以的
public class Test : NClay.Data.Mappings.IView
{
#region IView 成员

public NClay.Data.Mappings.Table GetTable()
{
DBContext.Employees.INNER(DBContext.Employees.ReportsTo, DBContext.Employees.EmployeeID).INNER(
DBContext.Employees.EmployeeID, DBContext.Orders.EmployeeID);
}

#endregion
}

人有不同的想法所以结构不一样很正常，
就算不同的人用MonoRail可能有着不同的结果,例如对于action里有的人喜欢直接ado.net处理SQL，有的人调用service处理那样。
框架提供个规范和约束（不过总会提供一些便利的基础功能），

@怪怪
做MS的竞争者自己做来yy一下还是可以的...
但如果想产品在市场化的时候压力非常大,客观事实的存在导致你的产品很难得人别人的认同(或者认同的人非常少).这样产品存在意义就大打折扣.

估计此功能的优势在于ajax调用webservice更新界面上...
我要是AJAX一个page返回html算了

其实直接用webform作为模板你就能省下不少事情.
用它的好处在于直接支持masterpage,usercontrol等等
语法上还能运用所有C#所具备特性.

@stan0714
项目是用2008开发的,DLL可以在05下面用.
主要代码也不多所以没有注释.

组件和代码生成的东西其目的都是一样.尽可能让用户更透明.
代码生成工具如果能达到和组件的一样的透明性那么和组件所发挥的作用没有本质上的区别.

看一下IL对方法的CALL然后说明更能明确问题.

大家座下来喝口茶吃个包不就完事了....
双方都主动点...大家都是男人老狗还害羞个了啊!

@蛙蛙池塘
那个不是linq而是我自己重写了运算符.

说实话没有什么资料...一般需要的时候到MSDN或google一下.
不过有时也很痛苦因为addin操作的是com所以不得不一个一个来试.
园子里的http://www.cnblogs.com/timiil 他在这方面总结的东西比我多了.
只是他不喜欢露出来.

@bidaas
按理是的。
但你会发现EntityBase所有可操作的方法都是protected，之于为什么这样干你看一下SmallData.VSGenerator的显示就能明白。

@金色海洋（jyk）
2.0
这是实现一个持久层的最基础部分，相对NClay.Data来说已经简化了不少。
不过其发挥的作用也不是很明显毕竟没有操作上的简化。
但在其基础上到底能发挥怎的作用可以看以下的一个扩展
http://www.cnblogs.com/henryfan/archive/2008/07/13/1241890.html

在上学的时候某本VB数据库编程的书就有这5条。

用word搞了。。。因为想画的时候发现电脑竟然没有UML等工具...

c#的socket异步不是已经具备IOCP功能了吗？

有一个固定稳键的就好.

实在不喜欢这两种方式,在用MonoRail就感觉不爽.为什么要在controller或action中加上filterattribute,为什么不在filter里描述这个filter的应用范围对象,非要在原来的地方搞上一腿.

其实设计的目的很重要是在于以后更容易修改和维护,对于接口约束的确起到一个很好的规则作用.但如果没有向高内聚低偶合进行靠拢的话...最终程序昨很能经得起考验.
对于怎样才能设计到高内聚低偶...我也不知道...我现在唯一的途径是通过不断的重构来实现代码的简洁.

现在这么多IOC组件都不用,可对对象生命周管理等一系列功能.
Yok说的是castle的ioc功能.

@datasky
具备了状态管理的对象都实现了IStateManager.
SaveState信息保存,而LoadState信息获取(这样东西会序列化保存到一个input里)当page post back后,所有控件状态信息都从自身的loadstate还源.
page load代码里的确是指同一个对象导致,一旦经过post back后即使同一个事件里设置两个selectvalue是不会出现你的情况的.

@datasky
主要那情况是这样,一旦post后从viewstate还原他们就已经是不同的object

@NetSpirit
@第一控制.NET
@曲滨*銘龘鶽
如果我在一个button event里设置SelectedValue 结果是不楼主那样?

@xiaosonl
NHibernate的model臃肿？臃肿在那里？
一个纯object,不需要继承base class也不需要实现interface.
即使实现了interface也不代表臃肿!

哦是我搞错了
我测了一下直接socket异步
接收:900044800节字
花费时间:3117.5942毫秒
服务端:
HFSoft.Net.NetServer server = new HFSoft.Net.NetServer(
new System.Net.IPEndPoint( System.Net.IPAddress.Parse("10.0.0.24"), 8088));
server.ChannelReceive += delegate(object o, HFSoft.Net.EventReceiveArgs e) {
lock (typeof(Program)) {
if (length == 0) {
sw.Reset();
sw.Start();
}
length = length + e.Data.Length;
if (length > 900000000) {
sw.Stop();
Console.WriteLine(length);
Console.WriteLine(sw.Elapsed.TotalMilliseconds);
server.Stop();
}
}
};
server.Start();

客户端:
HFSoft.Net.IChannel client = HFSoft.Net.NetServer.CreateChannel(
new System.Net.IPEndPoint( System.Net.IPAddress.Parse("10.0.0.24"),8088));
byte[] data = new byte[1024];
for(int i=0;i<1000000;i++)
{
client.Send(data);

}

byte[] buf = new byte[10240];
client.Send(buf);
........................
这东西在本机测根本没有意义的...

@怪怪
针对类或接口进行拦截的粒度大?其实有时想一下我们是不是真的需要对所有东西进行aop呢?
对于我个人而言在business logic function的层面上做aop就足够了.而business logic function往往又以interface service的方式公开.
不过话也说回来每个人的设计思路都不同,所以要是MS能提供我说的那种方法就更好了,MS只是留个机会给我们在jit前对method进行基于当前appdomain的修改:)