TOB - An ORM Replacement Unleashes Real Power Of Java OO Per

Could you just give me an example, to show something that TOB can do while JDO or ORM can not?

I don't mean disabilities about JDO/OODB, but just less elegant and more burdensome (manual consistency maintenance) than a true OO Persistent Model based persistent system. Yet with performance matters aside.

Let's talk with an example:
(download the runnable code from another post of mine, the Person class in family pattern there is a little more complex than here. but run tob.family.Test to see this example in action)

@MakeSwappable
public class Person extends TheObject
{
    @Kin(iAm = { "husband", "wife" }, thisIs = { "wife", "husband" })
    protected Spouse spouse;

    private String name;

    protected Person()
    {
    }

    public Person(String name)
    {
        this.name = name;
    }

    public String getName()
    {
        return this.name;
    }

    public Spouse getSpouse()
    {
        return spouse;
    }
}

@MakeSwappable
public class Marriage extends TheRelation
{
    abstract public class Spouse extends Role<Person>
    {
        protected Spouse(Persistent<? extends Person> person)
        {
            super(person);
        }
    }

    public class Husband extends Spouse
    {
        protected Husband(Persistent<? extends Person> man)
        {
            super(man);
        }
    }

    public class Wife extends Spouse
    {
        protected Wife(Persistent<? extends Person> woman)
        {
            super(woman);
        }
    }

    @Tie
    protected Husband husband;

    @Tie
    protected Wife wife;

    public Marriage(Persistent<Person> man, Persistent<Person> woman)
    {
        assert man != null : "Who is marrying noman?";
        assert woman != null : "Who is marrying nowoman?";

        this.husband = new Husband(man);
        this.wife = new Wife(woman);
    }

    protected Marriage()
    {
    }

    @Retying( { "husband", "wife" })
    public void newPair(Persistent<Person> husband, Persistent<Person> wife)
    {
        this.husband = new Husband(husband);
        this.wife = new Wife(wife);
    }

    public Husband getHusband()
    {
        return husband;
    }

    public Wife getWife()
    {
        return wife;
    }
}

Just these 2 source files, compiled, then at runtime, after we got a persistent person object, we can directly got his/her spouse as well as his/her marriage date.

Persistent<? extends Person> me = ...;

System.out.println("My spouse is: " + me.o.getSpouse().o.getName());
Persistent<Marriage> marriage = me.o.getSpouse().r().asPersistent();
System.out.println("We married at: " + new Date(marriage.getTimeCreated()));

How do you do the same with JDO?
(I mean to obtain relevant persistent object's attributes as well as the relation's attributes, which made the relevance)

TheRelation和TheObject的区别，很是模糊，在bookstore中，就只有Customer继承TheObject,其实按照你的思路，Customer都不该是一个TheObject，因为它也是一个Role，很多人和组织都可以扮演这个角色。

其他对象：
Product就是到Category的一个relation；
Category是其自身的一个relation；
Order是到Customer的一个relation;
OrderItem是到Order和Product的relation；

这符合你的自然感觉？

说实话，俺看着挺别扭。

看过代码的第一感觉是侵入的太厉害。看看各个类里面那么多相似的结构，似乎不用在写什么代码，直接代码生成，都可以。
试想一下，如果在这些代码中加入业务逻辑，那么，这种持久化代码和业务逻辑代码就会纠缠在一起。其实持久化只是业务对象的一个扩展而已，如果不考虑持久化概念，业务对象依然概念完整。
“分而治之”和“分离关注点”这些原则，是一个好的思路。业务方面和技术方面是可以分离的关注点，持久化属于技术方面。

有需要的时候 Customer 改为从 TheRelation 继承就可以了, seamless.



至少没有

	@CollectionOfElements(targetElement = OrderItem.class)
	@JoinTable(name = "ORDER_ITEM", joinColumns = {@JoinColumn(name = "ORDER_ID")})
	@IndexColumn(name = "linenum")
	public List<OrderItem> getOrderItems() {
		return this.orderItems;
	}

这些我看着更别扭的东西了.


所有那些都是在表达持久对象之间的逻辑关系, 通过Kin定义让它们之间建立起系统维护的物理引用.
大概除了TOB以外这些东西都要通过持久框架, 用关系模型的一些方式来体现, 所以你才会觉得这是 "侵入" 其实这些本来就是业务数据结构啊.

可以代码生成方面我还真没特别感觉到, 如果真是这样其实更好了啊, 直接从 ERD 派生 ORKD, 然后画图, 完了自动生成模型代码.


如果你觉得那些不是业务逻辑, 那

	private Integer id;

	@Id
	@GeneratedValue(strategy = GenerationType.AUTO)
	public Integer getId() {
		return id;
	}

	public void setId(Integer id) {
		this.id = id;
	}

这些又是什么?

还有

public class Category {
  ...
	public void setProducts(Set products) {
		this.products = products;
	}
  ...
}

这个呢? 既然是 public 的, 应该大家都可调用才是. 但应用代码, 业务逻辑的代码里能调用这个吗?


TOB里这些不是持久化代码, 我觉得更应该理解为数据模型定义.
且不说这样定义以后执行速度有几倍致上千倍的提升, 它在领域接口界定方面就让业务逻辑清晰很多, 不是你该用的东西就不给你看到.

没有持久概念的OO业务代码就只能通过调用非OO的持久化机制来完成本份工作, 所以打死也离不开非OO的数据库, 没法完全发挥OO的真正潜能(速度, 内存使用, CPU, 磁盘消耗等等). 纵使通过框架, 甚至AOP这种旁门左道来剥离其依赖关系, 也最终会受累不讨好 (用起来麻烦, 性能降低太多).

最后搞得持久化好像是很神秘多复杂似的, 其实你如果能在模型级别上接受一点点复杂度的增加, 换来的就是事半功倍的真正 OO 效果.

你没有理解我的意思。
在考虑业务逻辑时，我不用考虑对象持不持久化的问题，同样在考虑持久化的时候，我也不用考虑业务逻辑。
这就是“分离关注点”。
复杂的应用系统，如果没有处理好“分离关注点”的问题，那么，带来的就是混乱。

这就是我所说的没有持久概念的OO设计. 持久的实现不是业务逻辑, 但是持久的数据结构不是业务逻辑的一部分吗?

另外我没看出来ss的bookstore模型里完全是业务逻辑, 相反似乎持久相关内容的比例比TOB模型里的还要多. 同时给持久实现暴露的接口 (比如 setProducts()) 这些还在干扰业务逻辑接口.

贴一小段代码，AOP方式的持久化：

package org.sunflower.bookstore.order;

import java.util.Date;
import java.util.List;

import org.sunflower.DomainObject;
import org.sunflower.bookstore.customer.Customer;

public class Order extends DomainObject {

	public static final String STATUS_ORDERED = "1";

	public static final String STATUS_SHIPPED = "2";

	private Customer customer;

	private List<OrderItem> orderItems;

	private Date orderDate;

	/**
	 * 送货地区
	 */
	private String region;

	private String shipAddress;

	/**
	 * 实际售价
	 */
	private Double totalPrice;

	private Date shipDate;

	private String status;

	
	public static IOrderFinder orderFinder;
	
	protected Order() {
	}

	public Customer getCustomer() {
		return this.customer;
	}

	public void setCustomer(Customer customer) {
		this.customer = customer;
	}

	public Date getOrderDate() {
		return this.orderDate;
	}

	public void setOrderDate(Date orderDate) {
		this.orderDate = orderDate;
	}

	public String getShipAddress() {
		return this.shipAddress;
	}

	public void setShipAddress(String shipAddress) {
		this.shipAddress = shipAddress;
	}

	public Double getTotalPrice() {
		return this.totalPrice;
	}

	public void setTotalPrice(Double totalPrice) {
		this.totalPrice = totalPrice;
	}

	public Date getShipDate() {
		return this.shipDate;
	}

	public void setShipDate(Date shipDate) {
		this.shipDate = shipDate;
	}

	public String getStatus() {
		return status;
	}

	public void setStatus(String status) {
		this.status = status;
	}

	public List<OrderItem> getOrderItems() {
		return this.orderItems;
	}

	public void setOrderItems(List<OrderItem> orderItems) {
		this.orderItems = orderItems;
	}

	public String getRegion() {
		return region;
	}

	public void setRegion(String region) {
		this.region = region;
	}

	/**
	 * 取得价格合计
	 */
	public Double subTotalPrice() {
		Double subTotal = (double) 0;
		for (OrderItem item : orderItems) {
			subTotal += item.getUnitprice() * item.getQuantity();
		}
		return subTotal;
	}
}

package org.sunflower.bookstore.order.orm;

import java.util.List;

import org.hibernate.annotations.CollectionOfElements;
import org.hibernate.annotations.IndexColumn;
import org.sunflower.bookstore.order.*;
import org.sunflower.bookstore.customer.*;
import org.sunflower.bookstore.product.*;

import javax.persistence.*;

public aspect OrderPersistence {

	   declare @type : Order :
		   @Table(name = "ORDERS") ;
	   
	   declare @method :Customer Order.getCustomer() :
		   @ManyToOne;
	   
	   declare @method :Customer Order.getCustomer() : 
		   @JoinColumn(name = "CUSTOMER_ID");
	   
	   declare @method :List<OrderItem> Order.getOrderItems() :
		   @CollectionOfElements(targetElement = OrderItem.class);
	   
	   declare @method :List<OrderItem> Order.getOrderItems() : 
		   @JoinTable(name = "ORDER_ITEM", joinColumns = {@JoinColumn(name = "ORDER_ID")});

	   declare @method :List<OrderItem> Order.getOrderItems() :
		   @IndexColumn(name = "linenum");
	   
	   declare @type : OrderItem : @Embeddable;
	   
	   declare @method :Product OrderItem.getProduct() : @ManyToOne;
	   
	   declare @method :Product OrderItem.getProduct() : @JoinColumn(name = "PRODUCT_ID");
	   
	   declare @method :double OrderItem.getTotalPrice(): @Transient;
}

你觉得 OrderPersistence 这里的事情真的是你的本份吗? 写这么一个应用程序真的要一边实现业务逻辑, 一边实现持久功能??

持久实现是数据库的事, 本来不应该需要再编实现代码了, 这不是自己给自己包袱背么.

用TOB你直接定义你的数据想怎么样 "被持久", "被关联", 其他的事情完全不用操心了, 这是持久问题的原本复杂度, 也是我所能想到的最简单的.

对，确实是各干各的，要不我把它们分开干嘛？编写业务逻辑的时候，我可以丝毫不考虑持久化。