亚洲人成激情在线播放,亚洲色偷偷综合亚洲AVYP,久久久久亚洲爆乳少妇无

人在江湖 — Fri, 06 May 2011 16:22:00 GMT

XML曄��很火�Q�什么技术只要跟XML沾边儿就��上“标准”的光环�Q�后来大家慢慢意识到XML的种�U�弊端，比如差劲的表达能力，枯燥的解析（SAX�Q�，性能低下�Q�DOM�Q�，��来��多的�h开始理智地使用XML。只把它用在“合适”的时候。程序员中仍然存在滥用XML的惯性，最�q�还和同事们争论了半天java和xml的��用场景�?/p>

先跑下题聊聊java. �q�两�q�越来越多搞Java的�h跑去学动态语�a��Q�ruby, groovy, scala之类的�?原因在于�q�些动态语�a�“表达能力”更好。是的，�q�些语言更灵�z�，更精点{��不隄��解，后出的编�E�语�a�更們֐�于合理，毕竟它有前�h的宝�늻�验可以借鉴。java的一些设计的��o(h��)��病，比如checked exception, �Ҏ(gu��)��型支持的不完备。但��׃��“表辑֊�”来��_(d��)��我觉得java的表辑֊�不强不弱正正好好。Java的定位本来就是大规模企业�U�应用，�q�度灉|��的编�E�语�a�不易�l�护�?/strong>新型的动态语�a�們֐�于过度灵�z�，虽然支持快速开发，但是我相信在多�h�Q�甚臛_��十�h合作开发的��目中，如果对语�a�非常灉|��的特性不加以限制�Q�随着�E�序的规模一点点增大�Q�维护的隑ֺ��?x��)陡然加大。而一旦通过convention限制使用语言的一些特性，限制来限制去不就又成java了么�Q�好吧，好吧�Q�我知道�q�会(x��)是个有争议的话题�Q�我��是不相信用ruby能做个ERP出来�Q�五�q�之后也不会(x��)有。这不是�q�篇文字要讨论的重点�Q�我惌��的是�Q�java在表达能力方面已�l�让一些�h不满意了�Q�而XML呢？XML的表达能力比java差了N多个数量�U�！�q�年��_(d��)��骑三轮�R回收�?sh��)脑的都知道�E�序设计要有�Ҏ(gu��)��，换句话说�Q�能适应变化。于是一个简单的梦想��是�Q�来了新需求，�׃��用改code, �Ҏ(gu��)��xml配置��p��满��好了。是的，我也�q�么希望�Q�尤其在我睡着的时候。以Java�q�样的面向对�?+ 一些动态特性（reflection�Q�dynamic proxy甚至aspectJ�Q�的语言都很隑ց�到如此灵�zȝ��应对变化�Q�xml怎么�?x��)更��?gu��)��做到呢？很多人喜�ƢXML的简单直观。比如我们可以在SWING上面��装一层基于XML的界面引擎，于是GUI��可以简单地写成�q�种风格�Q?/p>

   1: <panel id=�?span style="color: #ff0000">xyz�?width=�?span style="color: #ff0000">360�?heigh=�?span style="color: #ff0000">720”…�?span style="color: #0000ff">>   2:     3: <label id=�?span style="color: #ff0000">label_1�?attr_1=�?span style="color: #ff0000">xxx�?attr_2=�?span style="color: #ff0000">yyy�?span style="color: #0000ff">/>   4:     5: <textarea id=�?span style="color: #ff0000">textarea_1�?attr_1=�?span style="color: #ff0000">xxx�?attr_2=�?span style="color: #ff0000">yyy�?span style="color: #0000ff">/>   6:     7: panel>

它有一个好处就是易于扩展，比如现在又想加一个checked box,只要在里面插入一�?lt;checkbox id=…�?>��p��了。我承认它的��易于扩展。但是如果你��单封装一下java API�Q�不也是一行code的事儿么�Q�无非就是panel.addChild(new CheckedBox(attr_1, attr_2))之类的这么一句code。难道这��׃��单，不直观了�Q�程序一涉及(qi��ng)到xml,��涉�?qi��ng)到IO, 解析XML�Q�这都是额外的工作量�Q�况且xml中的“对象”（我很难承认complex type��是对象�Q�跟Java里的对象�Ҏ(gu��)��不是一码事�Q�从xml里解析出来的表示数据�c�d��的type最后还是要生成对应特定的java对象�Q�这都是�ȝ��(ch��)事儿�?多写code的坏处远不止写的时候费事儿�Q�所写的每行code最后都是要�l�护的，��q��code很strong, 我还嫌code太长�Q�滚鼠标滚轮儿篏手指��_(d��)��多个文�g��N��儿篏��q��?strong>��M��Q�但凡xml改一两行能解决的问题�Q�不用xml,��q��java也是一两行的工作量�Q�只要稍微花点心思封装好API��p��?/strong>不用XML可以省不��开发和�l�护的工作。理��x��况下�Q�改改xml��p��应对新需求。但现实和理��x��L��有差距的�Q�一旦xml的schema不��以应对变化，我们��得改xml, 改schema�Q�改解析的code�Q�改业务逻辑的code�Q�这个没法避免）(j��)。这不是没事儿找病么�Q?strong>xml是extendable markup language. 它真能比java�q�extendable�Q?/strong>扯��E�Q?/p>
当然XML有它合理的应用场景，我能惛_��的是四个斚w��Q�一定有漏掉的情况，�Ƣ迎朋友们补充�?/p>
一�Q?存储�?w��i)状数据�Q��v码三层以上。三层或三层以下��q��java合成也挺方便的）(j��)�Q�二�Q?配置信息�Q�三、描�q�标准协议（比如wsdl�Q�；四，wrap数据以便于传输等(比如soap)

在应用��品中�Q�自��p��计xml来辅助应用系�l�的场景不应该很多�?/strong>

另有一�U��用xml的误区是�Q�把xml暴露�l�用戯��他自己“扩展”。我觉得�Q?凡是暴露�l�客��L(f��ng)��东西都是UI�Q��^时Swing界面�Q�web界面是GUI�Q�暴露给客户改的xml��是UI. 也许有的��Q�一旦弄GUI�Q�就有一堆麻�?ch��)事儿，比如i18n啥的�Q�让用户自己配置配置xml��p��改动��面不是挺好么，�q�不用考虑i18n了。问题是�Q�用xml不是“不用”考虑国际化，而是�Ҏ(gu��)��没法考虑国际化�?/p>
100 �q�个��国��看懂�Q�对中国人就得用<钱包><�?gt;100

�q�么做很明显用户体验很差。另外，�q�也一定程度上暴露了你的实现方式，��L(f��ng)��客户知道�Q�哦�Q�原来你是用xml存数据的�Q�schema��是�q�个样子�?/p>
Ajax刚铺天盖地的时候，都用xml传数据，后来��来��多人用Json. Spring和Hibernate�{�一堆框架在几年前都用巨大的XML来配�|�，现在��来��多��{向annotation(当然�Q�这个有一定争�?。XML热度减退�Q�大家趋于理性是好事。XML当然很有用，但是�E�序员们该能��x��楚什么是"使用", 什么是"滥用".

人在江湖 2011-05-07 00:22 发表评论

�ȝ��Domain Driven Design领域驱动设计认识DDD

人在江湖 — Sun, 20 Mar 2011 16:26:00 GMT

��好像第一�ơ读effective java才意识到什么叫做代码质量；�W�一�ơ接触到Domain Driven Design才开始认识什么是design。在之前的博客，分��n十二本经典电(sh��)子书�Q�涉�?qi��ng)java, OO design, spring, hibernate,struts2, agile 中，有DDD书的下蝲�?/p>
Domain Driven Design��Z��一些简单，重要�Q�务实的理念。下面根据自��q��理解�ȝ��DDD的基本理论�?/p>
1. 深刻理解Domain知识

DDD��Z��domain�q�行设计。前提是深刻理解领域知识�Q�需要持�l�学�?f��n)。另一个相关的实践是，“统一的语�a�”（ubiquitous language�Q�。领域专家所用的术语是准��的�Q�那么程序员讨论domain相关的问题时�Q�也应该使用�q�种术语。�ƈ且在写code的时候，也��用这�U�术语。这样做的好处是�Q�可以自然地把domain的东西map到code里，保持code反应domain�?/p>

2. 分层

Layered Architecture

�E�序需要分层，�q�是个简单的道理, 但需要真正�Ş成意识�?/p>
分别说说Domain Driven Design涉及(qi��ng)的四个layer.

2.1 Infrastructure�?/p>
主要从技术上对上面的各层提供支持。比如传送消息，持久化。UI层也可以分出更基��的component作�ؓ(f��)infrastructure�?/p>
2.2 UI�?/p>
UI层的作用是显�C�Z��息以�?qi��ng)解释用��L(f��ng)��输入命��o(h��)。重要的是UI层没有domain knowledge.

2.3 application�?/p>
application层的作用是描�q�C�品的外部功能�Q�它可以协调UI和Domain层的互动�?strong>application层应该很�?/strong>。它没有domain knowledge.

2.4 Domain�?/p>
Domain层是最重要的层。封装所有的业务逻辑�?/p>

DDD也从另一个角度分解��Y件。一个��Y件的�l�成部分�Q�building block�Q�包括association, entity, value object, service, module。其中比较强调的是entity, value object和service. service比较�Ҏ(gu��)��理解�Q�通常它是无状态的。它可以存在于application层，domain层或者infrastructure层。比较不�Ҏ(gu��)��区分的是entity和value object. entity��的是它的id�Q�而不是属性。强调它生命周期的��l�性和同一�?continuity and identity), �?strong>value object是用来“描�q�”entity�?/strong>。value object在很多时候适合是immutable的。这里需要注意的是，如果你会(x��)使用hibernate,你会(x��)知道hibernate里的value object通常不能reference多个entity�Q�换句话��_(d��)��能reference多个entity的，通常��是entity. 而在DDD的理��Z��Q?路线"是一个value object。而它可以reference�q�接"路线"的city(entity)和高速公�?entity)�?/p>

3. Domain Object生命周期

DDD的一个重要理论是关于aggregate. domain object之间的关�p�d��果非常复杂，在domain knowledge涉及(qi��ng)比较复杂的rule的时候，�Ҏ(gu��)��造成不一致的情况。解军_��法是�Q�把一些domain object放一个组里，让某个domain object作�ؓ(f��)根（aggregate root�Q? 所有对�q�些domain object的访问都要通过�q�个aggregate, 那么�l�持一致性的工作�Q�就限制在这个aggregate root里了�?/p>

另一个相关理论是factory和repository. factory是用来“创建”对象的�Q�是一个从无到有的�q�程。而repository是用来retrieve对象的，也就是说�Q�对象客观存在，只是没有攑֜�内存中，repository��是把数据从某个地方�Q�通常是数据库�Q�拿出来�Q�construct成对象的。一个常见的设计是，让repository暴露retrieve和create的api�Q�但是create的具体工作代理给factory来做�Q�也��是��_(d��)��factory通常被聚合在repository中�?/p>

人在江湖 2011-03-21 00:26 发表评论

人在江湖 — Sat, 05 Mar 2011 08:28:00 GMT
摘要: 转蝲自：(x��) Domain Driven Design and Development In Practice 好长的一��文章，从头到尾��M��一遍，写的挺好�Q�以后有旉��再读一遍，一些提到的内容�Q�比如Dozer�q�不了解�Q�有旉��了解一下！ Background Domain Driven Design (DDD) is about mapping business domain concepts into ... 阅读全文

人在江湖 2011-03-05 16:28 发表评论

人在江湖 — Tue, 01 Mar 2011 14:39:00 GMT

�q�是一��质疑DDD的好文，后面也脓(chu��ng)了一个回复，原文链接�Q?a title="http://techblog.bozho.net/?p=180" >http://techblog.bozho.net/?p=180

Eric Evans has formulated what domain-driven design (DDD) is. Martin Fowler is a great supporter and advocate of DDD. These are remarkable names and it is almost certain they are supporting something worth. And I’m not here to argue with that. Maybe I’m trying to justify the way I’ve been writing software, or maybe I’m trying just to clear things and be constructive. Let’s see.
What is at the core of domain-driven design �?the abstract notions of the domain, the domain model, the ubiquitous language. I’ll not go into details with that �?for those interested there is wikipedia (with lots of references to read in the footer). This is all very good in theory, and the domain-driven way of building software should appeal to everyone �?after all that software is being built for the benefit of that domain, not for the benefit of architects, developers or QAs.
But now comes the practical part �?how to implement DDD? I’ll answer that question in its contemporary context �?that is, using frameworks like spring and hibernate. And I’ll justify their usage. Spring is a non-invasive dependency-injection framework. DI is also strongly supported by Fowler, and is considered a good way to implement DDD. Hibernate is one way to use objects when working with a relational database. Another way is to use JDBC and construct the objects manually, but that is tedious. So hibernate doesn’t influence the architecture part �?it is an utility (very powerful one, of course).
Throughout this post I’ll use hibernate and spring as “given�? although they may be changed with any DI framework and any ORM or other persistence mechanism that relies on objects.
The accepted way to implement DDD with spring and hibernate is:

use @Configurable to make the domain objects eligible for dependency injection (they are not instantiated by spring, so they need this special approach)
inject repository objects in the domain objects in order to allow the domain objects to do persistence-related operations
use a thin, stateless, transactional service layer (a facade) to coordinate the domain objects

Implementation and description of this approach is shown in this extensive article. Another example (without spring) is http://dddsample.sourceforge.net/. I’ll discuss both later.
The alternative to this approach is the anemic domain model. It is considered an anti-pattern, but at the same time is very common and often used. The features of the anemic data model are simple �?the domain objects have no business logic inside them �?they are only data holders. Instead, the business logic is placed in services.
The reason this is considered an anti-pattern is because, first, this seems like a procedural approach. It is breaking the encapsulation, because the internal state of the object is, well, not internal at all. Second, as the domain object is the center of the design, it is harder to change it if its operations don’t belong to it, but to a number of stateless service classes instead. And domain-driven design is aimed at medium-to-large scale applications, which change a lot and need an easy way to make changes fast, without breaking other functionality. Thus it is important to have all the functionality of the object within the object itself. This also makes sure that there is less duplication of code.
So, instead of having a service calculate the price: ProductServiceImpl.calculatePrice(complexProduct) we should simply have ComplexProduct.calculatePrice(). And so whenever the domain experts say that the price calculation mechanism changes, the place to change it is exactly one and is the most straightforward one.
When simple operations are regarded, this looks easy. However, when one domain objects needs another domain object to do its job, it becomes more complicated. With the anemic data model this is achieved by simply injecting another Service into the current one and calling its methods. With the proposed DDD it is achieved by passing domain objects as arguments.
In my view, the domain object, which is also the hibernate entity, has its dependencies already set. But not by spring, because spring can’t know which exactly domain object to inject. They are “injected�?by hibernate, because it knows exactly which (identified by primary key) domain object should be placed in another domain object. So, a little odd example �?if a Product has rotten and has to dispense smell in the warehouse, it has to call, for example, warehouse.increaseSmellLevel(getSmellCoeficient()). And it has its precise Warehouse without any interference from spring.
Now, here comes another point where I disagree. Most sources (including the two linked above) state that repositories / DAOs should be injected in the domain objects. No, they shouldn’t. Simply calling “save�?or “update�?doesn’t require knowledge of the internal state of the object. Hibernate knows everything anyway. So we are just passing the whole object to the repository.
Let’s split this in two �?business logic and infrastructure logic. The domain object should not know anything of the infrastructure. That might mean that it should not know it is being saved somewhere. Does a product care of how it is stored ? No �?it’s the storage mechanism that’s “interested�? And here are the practical disadvantages:

CRUD is implemented by simply wrapping repository calls in all domain objects �?duplication of code
the domain object is transitively dependent on persistence �?i.e. it is not a pure domain object, and if repositories change, it has to be changed as well. And in theory it should be changed only when the domain rules and attributes change
people will be tempted to include transaction, caching and other logic inside the domain object

I’ll open a bracket here about a proposed solution in one of the above articles for making duplication of code, and boilerplate code easier to handle. Code generation is suggested. And I think code-generation is a sin. It moves the inability to get rid of duplicated or very similar code and abstract it, to tools. The most striking example is generating ProductDAO, CategoryDAO, WarehouseDAO, etc, etc. Generated code is hard to manage, cannot be extended and relies heavily on external metadata, which is definitely not an object-oriented approach.
Speaking of the repository, in the proposed examples each domain object should have a repository, which in turn will call the persistence mechanism. What do we get then:
User presses “save�?in the UI > UI calls save on the service (in order to have transaction support) > Service calls save on the domain object > domain object calls save on the repository > the repository calls save on the persistence mechanism > the persistence mechanism saves the object.
Is it just me, or calling the domain object is redundant here. It is a pass-through method that adds nothing. And since a lot of functionality is related to CRUD (yes, even in big business applications), this looks quite bad to me.
And finally, I find the @Configurable approach a hack. It does some magic in the background, which isn’t anything of the common language features (and is not a design pattern), and in order to understand how it happens you need a great deal of experience.
So, to summarize the big mess above

domain objects should not be spring (IoC) managed, they should not have DAOs or anything related to infrastructure injected in them
domain objects have the domain objects they depend on set by hibernate (or the persistence mechanism)
domain objects perform the business logic, as the core idea of DDD is, but this does not include database queries or CRUD �?only operations on the internal state of the object
there is rarely need of DTOs �?the domain objects are the DTOs themselves in most cases (which saves some boilerplate code)
services perform CRUD operations, send emails, coordinate the domain objects, generate reports based on multiple domain objects, execute queries, etc.
the service (application) layer isn’t that thin, but doesn’t include business rules that are intrinsic to the domain objects
code generation should be avoided. Abstraction, design patterns and DI should be used to overcome the need of code generation, and ultimately �?to get rid of code duplication.

=================================================

一个有见地的回复：(x��)

For one I think that technical issues should be separated from the functional domain. That means that domain objects should not be polluted by (technical) annotations or persistence methods (seperation of concerns). Dependency Injection (technical) should be outside the core domain. Persistence methods should be in a repository gateway, which (at least the interface, functional) is part of the domain. You know that you have a repository (functiuonal, within the domain), but not the way it’s implemented (technical). That’s outside the domain.
Just as the services (functionality) which calls them are part of the domain. These services are called from the user interface or other components outside this particular domain.
Transactional boundaries and session management is not domain functionality and should be outside the domain in a separate (thin) layer, which calls the services or domain objects within the domain.
DTO’s are useful for communicating outside the domain. In simple applications (with session management in the UI) the DO’s can be used, but I would not recommend it. I prefer the use of DTO’s which are assembled within the transaction boundary, and can be used outside the transaction (and session) boundary as to avoid potential LazyInitializationExceptions, which I am, unfortunately, very familiar with.
Dependency injection should not be in Domain Objects. If you want to use something like the AgeCalculator mentioned above, just call the user.getAge() method wich Alex suggested.
This method contains something like
class User {
public int getAge() {
AgeFactory.getInstance().getAgeCalculator().calculateAge(this);
}
}
The AgeFactory is a singleton, which has the correct calculator injected. You can use Spring for that.
class AgeFactory {
AgeFactory instance = new AgeFactory();
AgeCalculator ageCalculator = null;
public AgeFactory getInstance() {
return instance;
}
public void setAgeCalculator(AgeCalculator ageCalculator) {
this.ageCalculator = ageCalculator;
}
public AgeCalculator getAgeCalculator() {
return this.ageCalculator;
}
}
The implementation of the repository gateway objects can be done in the same way.
Usage of the repository (in a service) can be something like this
class ServiceImpl implements Service {
public void save(User user) {
RepositoryFactory.getInstance().getUserRepository().save(user);
}
}
These factories must be within the domain, because the domein objects must use them. But the dependency injection of these factories can be done outside the core domain (if you don’t use annotations). This way the core functional domain is not polluted with the technical issues of dependency injection.
Finally about annotations, I hate them, because it’s a magic black box. I rather use xml configuration files because they are probably easier to understand. Furthermore without annotations you can have the configuration files outside the core domain, and can use mock objects which are created and set on the factory without dependency injection within testcases. You can even choose to use dependency injection within part of the unit tests and without DI in other unit tests.

人在江湖 2011-03-01 22:39 发表评论

亚洲人成激情在线播放,亚洲色偷偷综合亚洲AVYP,久久久久亚洲爆乳少妇无

�ȝ��Domain Driven Design领域驱动设计 认识DDD

Layered Architecture

�ȝ��Domain Driven Design领域驱动设计认识DDD