You will be involved in system analysis and implementation for new business or system reconstruction, system consolidation, work with US and India colleagues with opportunity of oversea travel.

I assume you are good at .NET and XML,  have strong OO and reuse thinking, familiar with N-tier architecture. If you have on hand experience of SOA and system integration, experience of ecommerce and working with oversea teams that will be highly preferred. And of course, oral and written english, good communication and teamwork is a must here.

For general information, plz refer to http://www.51job.com/sc/show_job_detail.php?itisfrom=wudan&jobiduni=25883526

Send your english resume to yhonline@gmail.com. I'll contact you if you are the right person. Salary should range from 6k~12k (14M)

要知道他已经是两个孩子的爹了。

For understanding these terms, we turn to the definitions in The Unified Software Development Process [Jacobson, et al].

• A business model comprises two models: a business use-case model to describe the business actors and the business processes, and a business object model to describe business entities used by the business use cases.

• A domain model is defined as an abstract model that captures the most important types of objects in the context of the system. The domain objects represent the "things" that exist or events that transpire in the environment in which the system works.

Further, Jacobson et al state that the domain model is a simplified variant of the business model and the two terms are used interchangeably. This is exactly what we see in practice when analysts, designers and developers use the several terms interchangeably - business model, business object model, domain model, and domain object model. This usage dilutes these terms and renders them somewhat ambiguous.

In our discussion in this book, we use the term conceptual model to mean the abstract model, which mainly describes domain entities, their relationships and business rules. To describe a concrete object-oriented implementation model of a conceptual model, we use the term object model, which describes the classes and relationships used to realize a conceptual model. We use another term, data model, to mean the data implementation model, such as an Entity-Relationship (ER) model for an RDBMS database.

Model vali Form Data Validation Framework dation is performed by comparing the metadata and constraints to the model state. The metadata and constraints about the model are typically accessible from some sort of simple data store, such as a properties file. A benefit of this approach is that the system becomes more generic, because it factors the state typing and constraint information out of the application logic.

An example is to have a component or subsystem that encapsulates validation logic, such as deciding whether a string is empty, whether a certain number is within a valid range, whether a string is formatted in a particular way, and so on. When various disparate application components want to validate different aspects of a model, each component does not write its own validation code. Rather, the centralized validation mechanism is used. The centralized validation mechanism will typically be configured either programmatically, through some sort of factory, or declaratively, using configuration files.

Thus, the validation mechanism is more generic, focusing on the model state and its requirements, independent of the other parts of the application. A drawback to using this strategy is the potential reduction in efficiency and performance. Also, more generic solutions, although often powerful, are sometimes less easily understood and maintained.

An example scenario follows. An XML-based configuration file describes a variety of validations, such as "required field," "all-numeric field," and so on. Additionally, handler classes can be designated for each of these validations. Finally, a mapping links HTML form values to a specific type of validation. The code for validating a particular form field simply becomes something similar to the code snippet shown in Example 2.5.”

我取个名字叫 Form Data Validation Framework, 感觉这个东西蛮有用的（至少对我们公司这么多系统验证的逻辑老是在那里重复啊重复）。不知道.NET下面有没类似可用的东西，没有的话偶很想找时间做一个。

两年后再次翻阅《重构》，感觉很多手法已经很自然的融入到平时的开发之中。而平时开发中有时犹豫不决的地方，在《重构》里正好有最佳解决方案，看来还是温书太少。

有一点，不知道别人会否和我一样想，世事无绝对，比如书里提到消灭switch, 我曾经对一段简单的代码采用remove switch with state and polymorphism， 但是实在感觉那么简单的一个class没必要又抽象出N个子类和方法的多态实现，如此去处理，感觉反而不好维护不好理解。我担心会不会有时候别人指着书对着我的代码说“嘿，按重构手法，这里应该这样改...”，要知道系统总是会有很多trade-off,比如简单编码，效率，代码所有权等等，未必是按照重构手法就是最优的解决方案，书里面也提到了，先重构了碰到效率等问题的时候以后再调整，要知道有可能那段代码已经是trade-off之后的产物。

顺便提一点当前手上碰到的一个很难进行重构的场景：项目已经进入维护阶段，客户的需求是分批来，但是后来的需求可能很紧急需要比先到的需求提前发布，所以项目经理采用了版本控制“基线+分支”的方式，我在某个分支上如果做了重构，每次将分支合并到基线上去的时候简直是莫大的痛苦，而且很容易出错，而其它正在开发的分支以后再合并的时候又要痛苦一次。有时候会放弃重构，感觉就象是看着代码在慢性死亡。

还有个疑问：喜欢重构的人的家里面是一番什么样子呢？一个喜欢代码干净利落的人，会不会忍受自己家里面东西乱摆乱放象个狗窝样呢？至少我不太喜欢那个样子。

- Reduced cost by 57 per cent compared to other IT solutions for similar complex projects.

- Reduced effort by 62 per cent compared to alternatives, including in- house development and previously employed consultants.

- Reduced critical defects by nearly 80 per cent.

- Reduced overall defects by more than 60 per cent.

But I think, this report can't on behalf of the average ROI of agile development , because TW is so special, there are so many technical talents, not every company that practice agile development can do XP well, in result, it's hard to achieve such high ROI.

书我就不多介绍了，在J2EE社区挺热的。看到一半的时候，在JE上放了段话：

看了前面几章，有个大大的问号，J2EE without EJB，那为什么不用.NET呢？以前老说.NET上不了企业级，现在看来微软也不用造EJB.NET了。

在书里面看到说J2EE现在最大的优势是优秀的开源社区的支撑，这倒不假。不过.NET这边发展也很快，首先MS自己会搞很多东西出来，N多的J2EE平台开源框架也有了.NET版本。

在IDE,UI,Class Library,Cost方面, .NET都有明显的优势，数据库SQLServer2005，集成服务器Biztalk，工作流引擎MS WorkFlow Foundation， AJAX框架Atlas......

无意挑起任何争端，只想听听各位的分析，在以后的企业级系统方向上，J2EE的优势和机遇。


Robbin对此的答复 ：

先在看来又到了轻量级容器群雄格局的场面了，何时再能统一？相信不会太遥远....