Starting with objects

In current versions of Neo the domain model is defined in an XML file and this file is used to generate the object model as well as the database schema.

<table name="titles" javaName="Title">
    <column name="price" type="DECIMAL"	/>
    <column name="title" javaName="CoverTitle" required="true" type="VARCHAR" size="80" />
    <column name="title_id" primaryKey="true" required="true" type="CHAR" size="6" />
    <column name="pub_id" hidden="true" type="CHAR" size="4" />
   
    <foreign-key foreignTable="publishers" name="Publisher">
      <reference local="pub_id" foreign="pub_id"/>
    </foreign-key>
</table>

The object model comprises a TitleBase class that contains the generated code for the attributes and relations and a Title class that contains the custom code. Title inherits from TitleBase.

Feedback suggests that many people prefer another approach and would like to start with the objects rather than an XML file. The idea is that one defines the domain model in abstract classes and the Neo code generator uses these to create concrete implementations as subclasses; and the database schema of course. There would be no XML file in this approach.

The above model could be expressed as follows. You'll notice that the idea is that Neo 'guesses' default values, such as type and name, and you only need to specify those if there's an exception. For example, the property is CoverTitle which would be translated to cover_title as a column name. However, we want just title in the database so it needs to be specified.

[NeoEntity(table="titles")]
public class Title
{
    [NeoAttribute]
    public abstract Decimal Price { get; set; }

    [NeoAttribute(column="title", size=80)]
    public abstract String CoverTitle { get; set; }

    [NeoAttribute(primaryKey=true, type="CHAR" size=6)]
    public abstract string TitleId { get; set; }

    [NeoAttribute(type="CHAR" size=4)]
    protected abstract string PubId { get; set; }

    [NeoRelation(localKey="PubId", targetKey="PubId")]
    public abstract Publisher Publisher { get; set; }

    public void SlashPrice() 
    {
        Price = Price * 0.9;
    }
}

From the the code generator would create a class, say TitleImpl, that contains similar logic to the one found in TitleBase in the old model. A key difference is that the developers would not have to be aware of this as all the typing would be based on Title.

Labels

 
(None)
  1. Sep 14, 2004

    Ingo Lundberg says:

    It should probably say: public abstract class (not only for correct syntax, but ...

    It should probably say:
    public abstract class
    (not only for correct syntax, but the text also mentions abstract classes).

  2. Jan 25, 2005

    Paul Gielens says:

    If one would decide to make the extra mile, I'd prefer POCO.

    If one would decide to make the extra mile, I'd prefer POCO.