posts - 47, comments - 99, trackbacks - 5, articles - 2
  博客园 :: 首页 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理

2007年3月19日

     摘要: 在.NET世界中三层架构已经深入人心,是否有人考虑过另外的开发模式呢?  阅读全文

posted @ 2007-03-19 21:58 枫 阅读(2755) | 评论 (9)编辑

2007年1月29日

     摘要:   阅读全文

posted @ 2007-01-29 14:42 枫 阅读(1146) | 评论 (3)编辑

2007年1月6日

     摘要: 由园子里近期刮起的ORM旋风,结合自己的一些实际经验,谈谈自己对ORM的理解。  阅读全文

posted @ 2007-01-06 23:25 枫 阅读(13789) | 评论 (15)编辑

2006年11月26日

记得以前在看关于讲面向对象的书的时候都会拿Dog和Cat来做例子。比如他们都会叫,则他们都应该有个Bark方法,然后进一步抽象到Animal这个类。

然后进一步往深处讲,则会跟你谈到设计类的时候应该要关注这个类的行为,其实也就是方法了。同时它具有哪些对我们有用的字段和属性,这里我们不谈这个。

但是现在在实际的操作过程中呢?我感觉很多人都是拿了一个问题之后立即开始分析里面所包含的实体类,这个实体类有哪些字段和属性,完了以后加上CRUD方法,最后再在Business Layer里面根据界面的需求进行一通拼装。OK,Mission Complete!

所以在经过一段时间之后我就迷糊了。比如说在一个人力资源管理系统中,有一个人力资源部用户类HRUser,这个用户可以添加一条新雇员的信息,那么我想这个AddNewEmp的方法应该放在HRUser里面,因为是HRUser来做这件事的。但是实际做项目当中我感觉好像HRUser应该是一个实体类,里面不会给任何的方法,这个AddNewEmp的方法肯定会被写在别的地方,它的存在只是为了去响应用户在UI上点了添加雇员的这个按钮罢了。

中午也因为这个问题跟朋友讨论了一下,他说他喜欢实体类然后加控制器的这种做法。比如说你对Emp这个雇员类当作实体类的话,那么就应该有个EmpController,负责Emp的CRUD这些事情。这样做的好处在于分的很清楚。这样做确实是可以,但是如果这样那么好像我开头所讲的那种分析就没什么意义了,一切东西都能够做成一个实体类加控制器嘛。那么到底是书上讲的压根在实际工作中就行不通呢还是我们的做法根本就不是OOP呢?

到底应该怎样做呢?谈谈你的看法吧。

posted @ 2006-11-26 00:07 枫 阅读(8433) | 评论 (20)编辑

2006年11月23日

Document element (also can be called as root element) is needed for a valid xml document.

Xml namespace is done by defining the Universal Resource Indicator (URIs) which includes Uniform Resource Locators (URL) and Uniform Resource Numbers (URN).

There are 2 ways to define a namespace:
1). Default namespace: define it using the xmlns attribute without a prefix. For example: <html xmlns="http://www.w3.org/1999/xhtml">
2). Prefixed namespace: define it using the xmlns attribute with a prefix. For example: <blist:books xmlns:blist="http://www.wrox.com/books/xml">

DTD may either be stored internally as part of the XML document or externally in a separate file, accessible via a URL.
an internal example:

<?xml version=”1.0” ?>
<!-- DTD is not parsed as XML, but read by parser for validation -->
<!DOCTYPE book [
<!ELEMENT book (title, chapter+)>
<!ATTLIST book author CDATA #REQUIRED>
<!ELEMENT title (#PCDATA)>
<!ELEMENT chapter (#PCDATA)>
<!ATTLIST chapter id #REQUIRED>
]>

Extensible Stylesheet Language Transformation (XSLT) is a language used for converting XML documents from one format to another. The two below are used mainly:
1) Converting XML into HTML
2) Converting XML into another XML

Document Object Model (DOM): this API will laod the whole xml document into the RAM to do the parsing work. It is well suited for traversing and modifying an XML document, but provides little support for finding an arbitrary element or attribute. Of course it has the lower performance.

Simple API for XML (SAX): it loads the document as a stream of data parts instead of aggregation. It's straight-forward only.

Difference between SAX and DOM:
1) DOM uses a parallel approach to the document, it can access several different level nodes with one method. SAX only can starting at the beginning and responding to its contents once for each node and in the order they appear in the document.
2) DOM needs larger memory and has a lower performance. SAX needs smaller memory and has a higher performance. So if reading a very big xml document, using SAX is better.

As DOM doesn't support well for finding an arbitrary element or attribute, XPath can help us to do the work. It is a navigational query language for locating data within an XML document.

posted @ 2006-11-23 15:43 枫 阅读(59) | 评论 (0)编辑

2006年7月6日

Visual Studio 2005中对Web Project有一个Publish Web Site的菜单,你可以选择这个菜单来发布你的Web Project。

但是在第一次使用中就遇到了这个问题:


自己查看原因,原来是publish之后的precompile code试图将我Login页面的后台代码所对应的Login类转换为WebControls里面的Login类。大家知道.NET 2.0里面提供了一个Login的控件,其本身类的名称也是为Login。因此既然找到了这个原因,那么解决方案就很简单了,把你Login页面的类外面套一个Namesapce,并修改页面文件最上面的定义就可以避免这个错误了。

例子:

namespace MyPage
{
    partical 
class Login
    {
        
//your code here
    }
}

然后修改你的页面中的这部分为
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Login.aspx.cs" Inherits="MyPage.Login" %>


附:
1) VS 2005对发布Web Project的一个补丁:http://msdn.microsoft.com/asp.net/reference/infrastructure/wdp/default.aspx
2) 更多信息:http://weblogs.asp.net/scottgu/archive/2006/03/27/441147.aspx

posted @ 2006-07-06 09:08 枫 阅读(299) | 评论 (1)编辑

2006年6月8日

记得很久以前就看到过一篇文章,说搞不懂HttpModule,HttpHandler和HttpContext的算不上好的ASP.NET程序员。由此看来,在此之前我都算不上一个好的ASP.NET程序员。

要想搞清楚上面的几个东西,首先就要搞清楚当一个HttpRequest发送到服务器之后,服务器是怎么处理这个Request并且将处理的结果返回给客户端。在ASP.NET中,当一个HttpRequest到达服务器时,它会首先被inetinfo.exe截获,然后转交给ASPNET_ISAPI.dll处理。而ASPNET_ISAPI.dll则将请求转送到一个HttpPipeline的管道里面,ASPNET_WP.exe进程会接到请求并把它交给HttpRuntime来处理。如下图



那么请求在这个HttpRuntime里面又怎么工作呢?我们可以用下面的这个流程来表示:

HttpRequest ----> HttpApplicationFactory ----> 生成一个HttpApplication实例 ----> HttpModule ----> HttpHandlerFactory ----> HttpHandler ----> 生成结果传输回客户端,在这里我们已经可以看到HttpModule和HttpHandler了!

首先我们看HttpModule,它到底是做什么用的呢?
MSDN上的定义:http://msdn.microsoft.com/library/chs/default.asp?url=/library/CHS/cpguide/html/cpconHttpModules.asp
从中可以看到我们可以自定义编程HttpModule来实现对HttpRequest中的内容做一个处理或者过滤。下面的链接中可以转向一个MSDN的例子:http://msdn.microsoft.com/library/chs/default.asp?url=/library/CHS/cpguide/html/cpconcustomhttpmodules.asp,具体我这里就不多说了。

具体在这个例子中,我们可以看到我们是通过在IHttpModule接口中的Init方法中注册HttpApplication中的BeginReqeust和EndRequest事件来使我们可以在不同的阶段处理不同的事情。但是实际上,HttpApplication中包含了更多的事件,见MSDN链接:http://msdn.microsoft.com/library/chs/default.asp?url=/library/CHS/cpref/html/frlrfsystemwebhttpapplicationclasstopic.asp

再看HttpHanlder,先回顾一下上面讲到的HttpApplication中的那些事件:

[执行处理程序。]

PostRequestHandlerExecute

当进入到这个步骤时,HttpModule开始将Request转移给HttpHandler来处理,处理完的结果再转交给HttpModule发回到客户端。那么HttpHandler又怎么工作呢?其实跟HttpModule差不多,都是通过实现IHttpHanler接口,然后在web.config中注册自己的Handler来执行。

关于这个如何执行以及例子都可以参考MSDN,我想那边的可能更好懂一点。链接:http://msdn.microsoft.com/library/chs/default.asp?url=/library/CHS/cpguide/html/cpconaspnetrequestprocessing.asp

 最后关于HttpContext,它是在HttpApplication的实例创建出来之后就一直存在着,可以方便你的去访问HttpRequest中的一些信息。但是需要注意的是在使用里面的一些对象之前建议先弄明白里面一些对象的生命周期,否则可能会引发异常。更多的信息可以参考《ASP.NET Framework深度历险》一书。

关于实践:DNN中大量使用了自定义的HttpModule和HttpHandler来处理这些东西,所以如果有条件不妨去研究DNN,看看这些东西到底能为我们做些什么。

参考资料:
《ASP.NET Framework深度历险》
《DotNetNuke Friendly Urls》
MSDN
http://www.microsoft.com/china/msdn/library/architecture/architecture/architecturetopic/BuildSucApp/BSAAsecmodsecmod37.mspx?mfr=true

posted @ 2006-06-08 11:36 枫 阅读(730) | 评论 (1)编辑

2006年6月1日

昨天面试了一个人,所以工作报告上理所当然的就写了give an interview。但实际上正确的说法应该是conduct a job interview。

How-To Conduct A Job Interview: http://www.how-to.com/Operations/job-interview.htm

posted @ 2006-06-01 09:20 枫 阅读(124) | 评论 (0)编辑

1) sup - 什么事?好吗?即what's up的意思。
2) coz - 因为。because的缩写。
3) - 很棒的意思。我最经常遇见的就是我说我是中国人的时候,他们普遍回答说cool。
4) noob, newbie - 菜鸟。
5) yup, nope - 是,不是。
6) cya - see you.
7) brb - be right back,马上回来。
8) asap - as soon as possible.
9) LFG, LFM - looking for group, looking for more.
10) buff - 增益魔法
11) rdy - ready.
12) pst - please send tell,用传奇的行话就是M。
13) np - no problem.常见用法:-thanks for your help. -np.
14) WTB WTS - want to buy, want to sell
15) ty - thank you.不是讨厌,我记得有人在论坛抱怨说ty被人误解为讨厌,因此中国服务器慎用。
16) lol - laugh out loud. 虽然常用,但慎用。如果朋友之间倒无妨,但组野队有陌生人并不了解的时候,还是多使用haha, hehe。
17) OOM - out of mana. 没有魔法值。
18) pull - 引怪。通常让那些具有远程攻击能力的人去做。
19) res - resurrect. 复活。
20) respawn - 怪物刷新。
21) nvm - nevermind
22) ppl - people
23) wtf - what the fvck
24) suck - 令人讨厌的。经常可能会听到 XXX sucks,注意这是粗话。
25) OMG - oh my God
26) lmao - laugh my ass off
27) rofl - rolling on floor laughing
28) omw - on my way
29) a/c - account
30) j/k - joke
31) d/c - disconnect
32) ASL - age/sex/location
33) L2P- learn to play. 相应的可以延伸出L2duel, L2heal等等。

posted @ 2006-06-01 08:56 枫 阅读(164) | 评论 (0)编辑

2006年3月23日

进入新公司之后,开发方式跟以前相比变化很大。以前公司做的项目基本上没有什么文档,只有一系列的用户需求,然后根据需求来决定该怎么做,做成怎么样。但 在这里,动手之前首先需要准备User Story,即虚拟出最终用户的操作,写成文档来决定我们应该如何做,怎么去做。

最初,我是根据User Story的定义来定义好接口,然后根据接口编写Unit Test,最后去实现然后测试。当User Story并不是很复杂的时候,这种方法的确不错。然而,当你所要做的某些方法很复杂,需要考虑很多情况的时候,你会发现你的测试和实现可能会将你的代码 弄的一团糟,因为你要注意的地方太多了!

那么,这个时候,为什么不让我们的测试跟着我们定的User Story来走呢?

举个例子:有一个系统需要经常性的和服务器同步,那么对于第一次同步和以后同步肯定会有所差别。正常情况下我们很难去写一个测试直接去测试你的方法的所有 方面。但是如果根据User Story来编写测试呢?比如这里我们编写FirstSynchTest来测试第一次同步该做什么,SecondSynchTest来测试第二次同步该做 什么。这样,对于每次,我们只需要集中精力解决第一次我们要实现方法的某些功能,然后在第二次需要的时候再去考虑其他情况,但同时只要去保证第一次的测试 通过便可以了。

这样来做还有一个好处就是User Story和Unit Test是一个相互迭代的过程,在我们编写Unit Test的时候,也同时是对User Story的一种检查,因为Unit Test的编写直接去参考所编写的User Story。通常情况下对于我们开发人员只能给出一个我们认为用户该怎么做的步骤,并且很多时候,我们会遗漏一些简单的步骤。但在编写Unit Test的时候发现User Story是跳跃式的,于是回头添加User Story,然后继续更新Unit Test。

上面的方式最典型的一个例子就是在产品的升级中:最初做好的产品可能用户希望我们添加一些新的特性进去,但是这些特性会分散到用户操作的各个环节中。如果 按照User Story来编写的Unit Test,那么我们只需要回到特定的地方,加入新特性的Test,然后实现并测试,这样是不是觉得很直观呢?

总的来说这篇东西写的很枯燥,因为要将自己的一些体会写出来真的是很难。因为很多时候都是噢的一声,自己恍然大悟了,但是让你说出来却未必说的清楚。如果你觉得我的这种想法很危险,欢迎给我提出来

posted @ 2006-03-23 14:22 枫 阅读(922) | 评论 (7)编辑