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

除非你的team有一拨人专门管 "业务代码", 一拨人专门管 "持久代码"; 即便是这样, 交流成本可能就比定义模型的成本高了. 写aspect的人还得跟着写 "业务代码" 的人的屁股后面走, 然后还得定义一些隐性的规则约束 "业务代码" 编码风格, 不然写 aspect 的人怎么知道哪些应该怎么持久呢? 说回来还是要有人既考虑业务, 又考虑 "持久" 的.

(画外音: 按你这个AOP的例子, 这样写应用类的时候确实可以不考虑持久化问题, 但你不担心怎么搞一下就可能搞得持久不了了么? 要是我的话心里会不踏实的.)

所有这些本来并没有必要.

不需要一个team阿，就算一个人，这种分离也可以做到，一个时候只考虑一个方面的问题，看似多余，实则清晰哩。

好吧, 这个也是各人习惯问题.

我觉得用TOB是更倾向于 Declarative Programming, 你声明目标, 让系统自动帮你实现.

你自己先知道需要的一些目标可以先不用实现, 先专注于另一些目标实现好以后, 再去实现其他目标, 这样也是可以的.

不过用TOB你只需声明, 无须实现 (定义 ManyToMany/OneToMany, JOIN COLUMN等等这些, 我认为是持久实现的一部分), 所以总体工作量和开发迭代次数还是会有所减少的.

Why do you think I should care of the "relation's attributes"? Is it a practical concern or a "object-oriented" concern?

In most of the cases we don't care of the "relation's attributes", thus we just go with the simplest design.

class Person {
    String name;
    Person spouse;
    // ...
}

Sometime we do care of "the relation's attributes", then a relation becomes a model.

class Person {
    String name;
    Marriage marriage;
    Person getSpouse() {
        return marriage.getHusband().equals(this)?marraige.getWife():marraige.getHusband();
        // actually we can make this easier if we have an attribute of sex
    }
    //...
}

class Marriage {
   Person husband;
   Person wife;
   Date createdAt;
}

As long as JDO persists POJO, for sure you can persist/obtain object's attributes and the relation's attributes. Actually, if you don't have to make Person extends TheObject, I mean if you change your design to persist POJO, you can even implement JDO yourself! In that way, nobody will complain on "intrusive design" or "dependency". You can hide your implementation behind an elegant API, not let application developers aware of the TOB.

I noticed that in your code you always take relations as models. Is it a must of using TOB or just your preference?

This is a persistency nature of which Plain OO lacks its awareness.


So in your code do you aware the following is system logic and you are implementing it by yourself in application code?

        return marriage.getHusband().equals(this)?marraige.getWife():marraige.getHusband();
        // actually we can make this easier if we have an attribute of sex
}

And you have to worry more for a singleton whose marriage is null.
In addition, I don't think a JDO implementation can automatically fill both spouses' marriage reference, when a marriage relation is created; as to clear them when the marriage relation is deleted. This is also system logic, can JDO do that for you automatically? What's more, how about automatically chained delete, that when a person get deleted, his marriage relation automatically deleted as a reaction, then his spouse's spouce reference get cleared?  With TOB this could all be done automatically, by default semantics. (while you can prevent a person to be deleted by overriding the marriage relation's checking method)



You are right, I could have implemented TOB to be JDO compliant.

But you guess what? JDO is far from pleasing. TOB runs by default at the SERIALIZABLE isolation level, how could a JDO implementation guarrantee you? Simular to ORM, they can only delegate the ACID requirements to the underlying relational database, but since they implement caches themself, the serializability will be corrupted unless you entirely disable their cache mechanisms. How usable is a JDO/ORM without cache? Ask yourself this question.
TOB manages transactions at object level to fulfill ACID properties, so made TOB a real database instead of another O-R Mapper or another Transparent Persistence Layer.

So far I didn't mention about performance, if you havn't had a look at http://tob.ableverse.org/benchmarks.html and http://tob.ableverse.org/benchmarks/TOBvsJPOX/ . There are source code available for the benchmarks, download and run it yourself.

All these can NOT be done under the Umbrella of JDO or ORM, where TOB can not define a True Object Oriented Persistence Model of its own.

JDO tries to solve persistency problems in the Object Oriented way, but made the wrong choice to get rid of persistency natures (relational model) from OO semantics, it treats the relational model as persistence implementation instead of persistence definition, as a result the persistence supporting system can not fully serve the application in all aspects, for the lack of possible persistency requirements expressed by application data model.

Persistent applications need a way to express all of their persistence requirements, while POJOs with plain references can only express part of ALL. So a true OO Persistence Model is the essence to express the rest.


Do you know about the relational theory for databases? All grouped sets of attributes are relations in theory.
And in TOB a persistent class is a relation if it directly references other persistent objects. If a persistent class is only going TO BE referenced, it can inherit from TheObject, i.e. tob.bookstore.Customer

As my defense, I don't think this is "system logic". "A person within same marriage with you is your spouse" is a logic in the real world (target domain), not system domain. And so is "an unmarried person has no spouse".
Even in your client code, you must have implemented this logic somehow. You just don't know it. (Well, I assume you don't know it 'coz you said it's a system logic while it's not)

In you client code, a person's spouse is NOT a person, it's a Role of Spouse, which has a reference to a person. Interesting, but it's interestingly wrong. When I create models these models should match the target domain. A person's spouse should be a person. You mixed target domain and system domain.

How about "a car has 4 wheels, for each wheel there's a 'installed_date' attribute"? Something like "A Car has 4 Parts, each has a reference to a Wheel, while a Wheel has a Host, which has a reference to a Car"?


I'm not a big fan of JDO so I don't really know the answer( I prefer ORM but that's another story). However, I have a different assumption that JDO or JDO's implementation can do this. Cascading is kind of basic, there's no reason that they don't support it.


Could you give me a practical example that SERIALIZABLE level is mandatory? I found  default levels (READ_COMMITTED in most of the case?) work fine in my world. And I don't think "How usable is a JDO/ORM without cache" is a fair question. Look at the real world, ORMs work just fine!
I'm lost here. When you say "they can only delegate the ACID requirements to the underlying relational database", do you mean when TOB runs with a rdbms the ACID is managed by TOB not the rdbms? Or TOB added restriction while the rdbms manages ACID?


The charts look good. Congratulations!


Heheh... we come to this part finally.
Object-oriented (programming) and Relational (dbms) are just the ways we software developers look at the real world. Both OO model and Relational model have cons and pros. I mentioned earlier that I don't really like JDO. The reason is that it denies the relational nature of the world (hey, handshake?). IMO ORM does a good job of bridging the two so I prefer ORM over JDO.
Describing both OO aspect and relational aspect in a OO language is not a good idea. You think big, but you don't have a good tool on hand. Java is absolutely not a good choice since it only has OO nature. "Persistence<Person> john = ..." is ugly, so is "class Person extends TheObject", and so is "class Marriage extends TheRelation". "John's wife is  a Role not a Person" is even worse, to me it broke the baseline of Object-oriented, and you call it "True Object-oriented"!
You need a new language, a Relational Object Oriented language. In which you can write something like:

entity Person {
  Person spouse;
  //...
}
relation Marriage(Person,Person) {
  //...
}

However, in the poor Java world, POJOs and ORM still are the best choices. Maybe not because they are good, but because Java is poor.

I don't IMPLEMENT it, but DECLARE it, by the @Kin(iAm = { "husband", "wife" }) annotation, this way TOB gets to know the Spouse spouse; is referencing another person via the Marriage relation, thus further maintain this Kin reference for the app.

You are now just one step away from understanding the difference between Plain OO and Persistence Aware OO, that's there exist two different kinds of references:
Plain Object Reference, as

Person spouse;

and Persistent Reference as

Persistent<Person> spouse;

(After a careful examination, you'll find TheRelation.Role is subclass of Persistent, and Marriage.Spouse is subclass of TheRelation.Role)

In a PDM (Product Data Management) system, a wheel may according to a design model, which assigned a PartNumber. To model up a car, with 4 wheel of the same PartNumber, you attach the WheelPart to the Car, this way there will be a quantity attribute, having the value 4. If the quantity isn't a relation attribute, where would you put it?
Even in your situation (possibly in ERP flavor), when comes I want to distinguish the placement of each wheel, the FRONT-LEFT/FRONT-RIGHT/REAR-LEFT/REAR-RIGHT attribute is relation attribute or not?

Many relations have zero attribute, for these cases, they could be possibly merged with the entity class, this explains a previous question in this thread that why most of TOB persistent classes inherit from TheRelation. For example, the Pet class, it could be inheriting from TheObject, and having a separated PetOwnership relation to associate pets with pet owners, but since the PetOwnership has no attribute, and one Pet - one Owner, they were merged into a single Pet relation.


I'm always expecting a JDO expert to show me a solution to this problem in JDO way.


Not all realworld app need SERALIZABILITY, but surely there exists many need, i.e. banking applications. For everyday applications, it will also free you from some manual regulations. i.e. online shopping websites. After all, TOB's serializability is fairly cheap on top of the ORK Model basement.


Yes, TOB's ACID is on its own feet, it runs by default at SERIALIZABLE isolation level, while requires the underlying JDBC connection at READ_COMMITED.

As full ACID is a key measurement for any database system, TOB so certified itself to be a REAL database instead of a mapper or wrapping layer.


Thanks!


As I said above, make a single step out that begin accepting there are another kind of references - Persistent References, you'll find Java is not necessarily limited in the Plain OO frame, Java is also natural for Persistence Aware OO, without even any language extention. As the Inner Class infrastructure, which enables the semantic of TheRelation.Role as to be inherited, gives it this full ability. While having a common persistent root class (TheObject), and relation class (TheRelation) is just the lanuguage semantics to distinguish persistent objects from transient objects.

What ever, my point is "it's not system logic". Implemented with annotation or old Java code doesn't make much difference in sense of "implemented with Java".


Heheh... you think I'm talking about the spouse of TheRelation?
No, I'm talking about spouse of Person

public class Person extends TheObject  
{  
    @Kin(iAm = { "husband", "wife" }, thisIs = { "wife", "husband" })  
    protected Spouse spouse;  
  
    private String name;  
    //...
}   

Read my post again! Or I don't mind to repeat once: A person's spouse is not a person!


Let me re-ask the question in a different way: How will you reference a Car in a Wheel class and how will you reference Wheels in a Car class? There must be something in place of "Role" in "Marriage", right?


I suggest you get a copy of JDO spec and read it first.


That's just your assumption. I worked on banking systems for years and never need it.


Understood. Just as what I thought. Implementing SERIALIZABLE level on a memory based db can be cheap, but still I don't think it a big plus.


I have expressed my opinion enough in this place and I don't wanna repeat it.

What don't you ask this question to yourself: What does TOB offer to client application programmers?
Is modeling simpler with it?
Is programming faster with it?
Are programs easier to be tested with it?
Are programs easier to maintain with it?
...

My answers are NO NO NO NO.

It's the difference of implemented by DB or by App.
Do you know the concepts of Declarative Programming?


I am talking the spouse in Person, too!
You can safely cast Spouse spouse; as (Persistent<Person>) spouse; Do you aware this?


The Role is defined as a subclass of Persistent<T extends Person>, while with added hint to TOB that this persistent reference is via its outer class: Marriage.


I read through JDO spec 1.0 3 times, and 2.0 1 time.


Did your app process money transfers?


Okay, not much valuable to you.


Yes, you can expect the model code to be generated from ORK Diagrams in the future, just as someone draws ERD to generate DB Schemas.
Anyway, it is plain Java sources even for now.
Well, you definitely feel hard from a thing you havn't learnt.


It will, after you accept its methodology and mastered the basic skills.


Sure, why not? you just run your program, without even touch a RDB!
Whar are you expecting?


It's clear java program structure, much easier for static analysis tools to perform focused analysis on it. Of course, after you accept Object Oriented Relational Persistence Model.


If you refuse to accept new concepts and methodologies from TOB, you are not going to change your answers.

I'm tired of doing this. This is going to be my final reply.


I said "it's not system logic".
The person within same marriage with you is your spouse, this is not system logic.
Declarative Programming is still programming, 'coz the system doesn't know you logic.


You can cast it into Persistent<Person>, yeah, but you cannot cast it into Person. Are you aware of this?
A person's spouse is not a Person.


I'm talking about another kind of relation ship: composition
I used car and wheels as an example but you never ever get it.


Then you need to learn how to read. Seriously! I found that you are having a problem reading my post, and it seems that you don't even know some of the basic things of JDO. You even doubt if JDO can do cascading, how did you read them?


Are you kidding me? What do you think banking systems do? You don't really understand the different isolation levels.


I can expect? In POJO world I can already do this. My question was "simpler" and you didn't answer my question.


That's sneak. If I cannot program faster with it, you can still say that. But I don't think writing more classes can be faster than writing less classes.


I'm expecting the ability to test models separately, automatically, and to let me do a test driven programming.


To describe the "person-marriage" model, how many classes do you need? In POJO world, I need just two. Are you saying more classes are easier to maintain? In POJO world a person's spouse is a person. Are you saying a more complicated system is easier to maintain?
To maintain a software means to do bug fixing, to do enhancement, and sometime to do migration. Are you saying applications based on TOB is easier to migrate?

I cannot keep doing this. That's it. Bye.