不错，正在学习C#，收益，O(∩_∩)O谢谢
SORUCE:http://www.cnblogs.com/hcl0208/archive/2009/04/18/1438641.html
简单的测试了一下IE前进和后退的过程.
依次访问网站A,B,C,D.
后退至 B,
然后重新请求网站E,
则记录的保存顺序则是 A,B,E
C,D将会从记录列表中删除.
下面看代码(以下操作均在内存中进行):
一个History对象,用来生成一个记录对象,该对象包含 url,title,html三个属性.
class History {
private string Title_ = ""; private string WmlSource_ = ""; private string Url_ = ""; public string Title
{ get { return Title_; } set { Title_ = value; }
} public string WmlSource { get { return WmlSource_; } set { WmlSource_ = value; } } public string Url { get { return Url_; } set { Url_ = value; } } public History() { } public History(string t, string w, string u) { Title_ = t; WmlSource_ = w; Url_ = u; }
}
HistoryAction是对链表操作静态类,具体看代码注释
Code
页面调用方法
Code
OK,搞定,实际上非常简单,这里可以看到LinkedList的方便之处了.对性能的处理请自已把握.
好了,如果有不合理的地方请大家指正.
Feedback
好文要顶..............
============================
http://www.itstrike.cn/Home.mvc/Search?key=%E7%AE%97%E6%B3%95
============================
http://www.itstrike.cn/Home.mvc/Search?key=%E7%AE%97%E6%B3%95
仅仅url的双链表是不足以完成浏览器的历史功能的
前进后退的时候 大多数表单和 <script src="/Script/common.js" type="text/javascript"></script>
<script type="text/javascript"></script> <script src="/WebResource.axd?d=PyW-m2hLmppJ9byT1bYEqw2&t=633595624754539605" type="text/javascript"></script> <script></script> <script></script> <script src="/ScriptResource.axd?d=keXr1l0ODizNGwpG5umihnLbiZlZFmnBNv9PADikeydJNFn_nnzWP6nCtj5LEvCjoGqazIbHl5iuU6pakvSNXw2&t=2874222d" type="text/javascript"></script> <script src="/ScriptResource.axd?d=keXr1l0ODiwWLTaLPM0Wf5tBD4Fzsw_srZZaAdk-sMwIKi6Tu5xOvlE51KHVONvwxleyMMKz8jO0AA_0T9c673x1SZuv0_7-0&t=ffffffff87f27a50" type="text/javascript"></script> <script src="/ScriptResource.axd?d=keXr1l0ODiwWLTaLPM0Wf5tBD4Fzsw_srZZaAdk-sMwIKi6Tu5xOvlE51KHVONvwxleyMMKz8jOFzTNgB8GMtHRFqd4TqugJo5GHPjCn6A41&t=ffffffff87f27a50" type="text/javascript"></script> <script src="../../../../../WS/AjaxWS.asmx/js" type="text/javascript"></script> <script type="text/javascript"></script> <script src="http://www.cnblogs.com/Files/JeffreyZhao/jquery-1.2.1.pack.js" type="text/javascript"></script> <script src="http://www.cnblogs.com/Files/JeffreyZhao/say.no.to.ie.6.js" type="text/javascript"></script>
前进后退的时候 大多数表单和 <script src="/Script/common.js" type="text/javascript"></script>
| |||
|
<script type="text/javascript"></script>
辅助方法不嫌多Posted on 2009-04-12 19:25 Jeffrey Zhao 阅读(3582) 评论(29) 编辑 收藏 网摘 所属分类: 02. ASP.NET, 05. 实践优化
经过了一些《表达式树》、《尾递归》等冷门内容，我们再回到一些人民群众喜闻乐见的话题上来，继续《最佳实践》的讨论。 在开发项目过程中，总是会出现大量的辅助方法，例如字符串处理，代码检验，格式输出等等。如果您发现自己在多次编写类似的代码，可能就要想着如何把这些代码进行提取，变成辅助方法（亦或是类库甚至框架，关于这方面粒度问题在此不作讨论）。辅助方法的作用除了遵循DRY原则之外，也能让代码更容易编写，更为清晰，可读性也能更好——而且只要您“去做”，就会发现要得到这些好处并不困难。 在这里举一个最简单的例子，对Index方法的单元测试： [TestMethod] public void IndexTest() { UserIdentity identity = new UserIdentity(); Mock<HomeController> mockController = new Mock<HomeController>() { CallBase = true }; mockController.Setup(c => c.Identity).Returns(identity); var result = mockController.Object.Index() as ViewResult; if (result == null) { throw new Exception("result is expected to be ViewResult but not."); } Assert.AreEqual("", result.ViewName, "the view name is expected to be the default one but '{0}'", result.ViewName); Assert.AreEqual("", result.MasterName, "the master name is expected to be the default one but '{0}'", result.MasterName); var model = result.ViewData.Model as IndexModel; if (model == null) { throw new Exception("model is expected to be IndexModel but not."); } Assert.AreEqual(identity, model.Identity); Assert.AreEqual("Welcome to ASP.NET MVC!", model.Message); } 从“var result = ...”这一行代码开始到结尾，都是对Index方法调用结果的断言，其中包括以下几点：
这不可或缺的五点要求总共占用了十几行代码（虽然它们都非常清晰明白）。如果每个单元测试方法都需要编写这些代码，这无疑是一件令人乏味的事情。这时，您就可以提供辅助方法来简化单元测试的编写。 “等一下，你说要为单元测试编写辅助方法，这值得吗？”的确，老赵也见过不少朋友认为，为这种“非功能性”的代码投入太多成本是一件价值不大的事情。其实关于这一点和讨论“单元测试是否有必要”是差不多的事情，如果您把单元测试视为一种可有可无的辅助品，那么的确不值得这么做1。如果您认为单元测试是项目的一部分，那么让这部分代码更容易编写又有何不可呢？更何况……您不妨先看一下使用辅助方法之后这部分代码的模样： [TestMethod] public void IndexTest() { UserIdentity identity = new UserIdentity(); Mock<HomeController> mockController = new Mock<HomeController>() { CallBase = true }; mockController.Setup(c => c.Identity).Returns(identity); var result = mockController.Object.Index().Is<ViewResult>().IsView(null, null); var model = result.ViewData.Model.Is<IndexModel>(); Assert.AreEqual(identity, model.Identity); Assert.AreEqual("Welcome to ASP.NET MVC!", model.Message); } 不知道您的感受如何，不过这些代码当时的确让老赵欣喜了一把。长篇冗繁的判断代码变成寥寥数行，而且如果您也可以想象一下在编写这些代码时的感觉——几乎都由IDE提示完成。而且，编写这些辅助方法其实非常容易： public static class AssertHelpers { public static T Is<T>(this object result) { Assert.IsTrue( result is T, "actionResult is expected to be '{0}' but '{1}'", typeof(T), result.GetType()); return (T)result; } public static T IsView<T>(this T result, string viewName, string masterName) where T : ViewResult { viewName = viewName ?? ""; masterName = masterName ?? ""; Assert.IsTrue( String.Equals(viewName, result.ViewName, StringComparison.InvariantCultureIgnoreCase), "The view name is expected to be {0} but {1}", viewName == "" ? "the default one" : "'" + viewName + "'", result.ViewName == "" ? "the default one" : "'" + result.ViewName + "'"); Assert.IsTrue( String.Equals(masterName, result.MasterName, StringComparison.InvariantCultureIgnoreCase), "The master name is expected to be {0} but {1}", masterName == "" ? "the default one" : "'" + masterName + "'", result.MasterName == "" ? "the default one" : "'" + result.MasterName + "'"); return result; } } 这里用到了C# 3.0的“扩展方法”特性，这是个非常重要的“语法糖”。由于没有任何的侵入性，在实际使用过程中，扩展方法的美妙之处往往体现在一些非常有趣的地方，例如：
此外，测试代码的可读性也提高了一个级别，我们使用了Is…IsView等方法“模拟”了自然的英语语法。在Java和C#等语言中实现这种自然的文法并不是一件简单的事情（相对于Ruby，F#等语言来说）。不过我们也可以朝这个方向去努力一把，而最后的结果似乎也令人较为满意。 在这里还有个题外话：如今API的优劣已经大大影响一个语言、平台、框架在开发群体中的地位。开发人员往往会因为“顺手”这个看似“无理的理由”改变自己对于某个框架、平台或者语言的选择——其实原因也很容易理解，因为良好的优秀的API设计能够大大提高开发效率。这是个不争的事实，我们有时会说某某语言“它就是在写英文啊”（例如传说中的AppleScript），其实就是再指这门语言在描述程序的“语义”时与真实语法特别接近。举个更贴近.NET的例子，使用NMock，RhinoMocks这两个.NET单元测试领域中大名鼎鼎的Mock框架对一个方法调用作期望（Expect）时，就可以看出它们在API设计上就有很大的不同： interface ICalculator { int Sum(int a, int b); } class TestFixture { void TestByNMock() { var mocks = new Mockery(); var mockCalculator = mock.NewMock<ICalculator>(); Expect.Once.On(mockCalculator) .Method("Sum") .With(1, 2) .Will(Return.Value(3)); // use the mockCalculator object... mocks.VerifyAllExpectationsHaveBeenMet(); } void TestByRhinoMocks() { var mocks = new MockRepository(); var mockCalculator = mocks.CreateMock<ICalculator>(); Expect.Call(mockCalculator.Sum(1, 2)).Return(3); mocks.ReplayAll(); // use the mockCalculator object... mocks.VerifyAll(); } } 作为流行的Mock框架，无论是NMock的Expect...On...Method...With...Will Return式语法，或者RhinoMocks的Expect.Call...Return式语法在编程的“语义”方面都做得不错——不过Rhino Mocks明显更胜一步2。其原因就在于RhinoMocks使用了显式的方法调用和参数传递替代了NMock的字符串传递语法。这个优势使得开发人员在编写单元测试时可以在编机器中得到良好的代码提示，在重构时也可以让编辑器同时修改Mock对象的方法名，至少也可以让编译器提示错误。反之，如果使用字符串，则在Mock方法名修改之后还必须在运行时才能发现问题。一个简单重构就会破坏数个甚至更多的单元测试，这无疑是一个令人沮丧的现象。 作为一个从VB 5/6（2年）转向Delphi（1年），后又转向Java（1年半），最后立足于.NET平台，同时也在不断地关注着各类语言/平台发展的开发人员，我的看法应该不是井蛙之见。微软的产品以“易用性”著称，这一点在其开发领域也得到了继承。在对语言特性和API设计这方面，.NET平台总体来说让我非常满意。例如在.NET里使用C# 3.0的特性进行开发经常让我有一种愉快的感觉。.NET框架在其大部分类库中也提供了非常方便、直观的API设计，在编辑器的代码提示帮助下，一个有经验的开发人员甚至可以摆脱文档来写出一段能够“解决问题”的程序来。而微软在.NET框架中提炼出来的设计准则也被写入了《Framework Design Guidelines》一书中，它是第16届年度Jolt大奖的图书，现在其第二版也已经上市。我想您应该不会错过这些。
注1：如果您觉得单元测试可有可无，那么可能ASP.NET MVC并不适合您，您不妨继续使用更容易掌握的ASP.NET WebForms框架。 注2：Moq利用了Lambda表达式在语义方法又比RhinoMocks更胜一筹，不过现在RhinoMocks目前也提供了类似的功能。 Feedback#2楼 回复 引用2009-04-12 19:32 by @^o^@ [未注册用户]
不会吧,你瘦身如此成功!
说实话,你本应该用DV拍下整个过程,片名就叫《大肥鹅变健美男》。。。。。
@@^o^@
我也后悔了应该每天拍一张照片的 #5楼 回复 引用2009-04-12 19:41 by xiao_p(未登陆) [未注册用户]
老赵嗷嗷瘦，这图片是老赵不？
#6楼&n件AdSelect发布(提供下载)
最新评论
| |||
1282
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
