AlachiSoft Announces TierDeveloper 3.0 O/R Mapper

Discussions

News: AlachiSoft Announces TierDeveloper 3.0 O/R Mapper

  1. AlachiSoft has announced TierDeveloper 3, an object-to-relational mapping and code generation tool. Version 3 supports dynamic queries, .NET, integrates with Weblogic 8.1, JBoss 3.2.x, MySQL, and enhances Oracle support.

    Check out TierDeveloper 3.0.

    Threaded Messages (17)

  2. Why O/R tool[ Go to top ]

    Hmm...I'm not sure why people are still using O/R tools...
    It keeps your code "polluted" with proprietaty stuff. Sure you can go there and put
    some "enchancements". But in practise, how often does it happen?

    I think JDO is a good VENDOR neutral answer to Object to relational mapping.
    No code changes (only byte code update)

    I wonder if some of these O/R vendors would create JDO implementation?
    I guess it would never happen - sunce they would risk to set free their customers...
    Right now all O/R customers are locked with particular vendor....
  3. Why O/R tool[ Go to top ]

    I am not too familiar with TierDeveloper, but by glancing at their product overview page, looks like one of the features they differentiate themselves with is .NET integration.

    I find it powerful to have the ability to generate common domain model for Java and .NET runtimes and then use common technique to persist it.

    Regards,
    Dmitriy Setrakyan
    Fitech Labs, Inc.
    xNova™ - Service Oriented Technology for Java and .NET
  4. Why O/R tool[ Go to top ]

    I'm not sure if support for .Net and Java is a good reason to use this O/R tool.
    Unless your development shop has both: .Net and Java applications...
    Well, may be I'm out of touch with the reality... but I don't think that is the common case on the market...
    I personally don't see how one could take advantage of it.

    For interfacing between different apps (.Net and Java) you could use WebServices...
  5. Why O/R tool[ Go to top ]

    It is actually quite surprising that .NET has nothing standard in support for O/R mapping...like Java has standard JDO.

    I think .Net has some room for improvement...
  6. Why O/R tool[ Go to top ]

    It is actually quite surprising that .NET has nothing standard in support for O/R mapping...like Java has standard JDO.

    >
    > I think .Net has some room for improvement...

    Microsoft will add ObjectSpaces in their next .Net version. ObjectSpaces is to .Net the same as JDO is to Java.
  7. Why O/R tool[ Go to top ]

    Microsoft will add ObjectSpaces in their next .Net version. ObjectSpaces is to .Net the same as JDO is to Java.


    Good to know this! I think it eventually we might have tools to migrate ObjectSpaces to JDO and vs versa...well at least mappings and classes
  8. Why O/R tool[ Go to top ]

    Microsoft will add ObjectSpaces in their next .Net version. ObjectSpaces is to .Net the same as JDO is to Java.

    >
    > Good to know this! I think it eventually we might have tools to migrate ObjectSpaces to JDO and vs versa...well at least mappings and classes

    Almost everything in Microsoft development is proprietary, so I would not expect any similarity, but only a JDO to Objectspaces migration tool from Microsoft.

    Floyd has created a thread about .net objectspaces
  9. Why O/R tool[ Go to top ]

    <quote>
    It is actually quite surprising that .NET has nothing standard in support for O/R mapping...like Java has standard JDO.
    </quote>

    I agreed. When it comes to data tier, .NET seems very immature while J2EE has lot of options like Entity Bean, JDO and OR Mapping tools.

    In my personal opinion it is good that some one finally came up with the O/R mapping tool for .NET too.

    BTW I have played little bit with Tier developer and it seems they have done a pretty good job. The only criticisms (postive one) I have is that they use COM+ transaction services (according to my understanding) to control the transaction in .NET environment, in my persoanl opinion it may not be necessary or over kill most of the time.
  10. Why O/R tool[ Go to top ]

    I'm not sure if support for .Net and Java is a good reason to use this O/R tool.


    It may not be a good reason to you (if you are in a pure Java shop), but to IT organizations that have Java and .NET connecting to the database - it is definitely something to consider.

    Regards,
    Dmitriy Setrakyan
    Fitech Labs, Inc.
    xNova™ - Service Oriented Technology for Java and .NET
  11. TierDeveloper vs. Hibernate[ Go to top ]

    Everybody has another preferences. I used old JDO implementation from SUN and I was not very satisfied (I don't like when my bytecode is different from my source). Now I am using Hibernate - it is a great. It is very simple for using,no changes in bytecode, connection to database is describe in property file. Becasue I am programming web applications I appreciate possibility set up different cache behaviour (without programming - only changes in property files) for every table.

    Maybe TierDeveloper is better as Hibernate (at least it has nice GUI), price is not so much, but unfortunately TierDeveloper don't support my database.
  12. TierDeveloper vs. Hibernate[ Go to top ]

    I used old JDO implementation from SUN and I was not very satisfied (I don't like when my bytecode is different from my source)


    Well, since then lots of things have changed...Right now there are lots of commercial JDO implementations. I used some of them and was quite surprised how quickly & easy I could get things work...
  13. Database support[ Go to top ]

    Hi,

    Which databse are you using? TierDeveloper Supports:

    MSSQL
    Oracle
    IBM DB2
    MySQL
  14. JDO implementations[ Go to top ]

    You can find very many good JDO implementations, even open source. You should check www.jdocentral.com.

    I have worked with Kodo ( www.solarmetric.com ) and I was VERY satisfied with it. I have also worked with open source TJDO ( http;//tjdo.sf.net ) which is quite good.
  15. Why O/R tool[ Go to top ]

    I do not think many large apps are writen with O/R mapping.
    Most large apps are writen with tabluar data (RowSet, ResultSet, iBatis, Jakarta Commons SQL, ODBC, etc.) Tabular mapping represents the data much more accurently, in a set theory.

    Even OMG is backing away, going towards the Model Driven Architecture.

    For example, it is much harder to do a multi row nested update with O/R, and that is one of the issues with EJB like aproaches.

    .V
  16. Why O/R tool[ Go to top ]

    I do not think many large apps are writen with O/R mapping.

    > Most large apps are writen with tabluar data (RowSet, ResultSet, iBatis, Jakarta Commons SQL, ODBC, etc.) Tabular mapping represents the data much more accurently, in a set theory.

    Vic, you keep repeating that, but I respectfully disagree. Of course, OLTP and similar scenarios with batch processing may require JDBC-style tabular data access. On the other hand, O/R mapping suits many typical application models nicely, especially ones based on entities that get handled and updated on an individual basis most of the time.

    For occasional batch update requirements, you can always fall back to plain JDBC for a particular use case. You'd have to invalidate any affected O/R mapping caches, of course. This is pretty straightforward with Hibernate for example, especially combined with the Spring Framework's transaction management across heterogeneous data access objects.

    BTW besides out-of-the-box Hibernate and JDO support, Spring offers a decent JDBC access framework, simplifying many tasks via Inversion of Control. This is somewhat comparable to the iBatis Database layer, although more generic. It can be used as library on its own, or well-integrated with a Spring-managed middle tier - just like most parts of Spring.

    Note that I do see value in tabular data access. It's not about tabular access vs O/R mapping. They simply match different persistence use cases, respectively different application types. DAOs that contain course-grained data access units-of-work can help a lot to abstract the actual persistence strategy, be it O/R mapping or tabular, in combination with generic transaction demarcation.

    Juergen
    Spring Framework developer
  17. Nice product with unusual feature (.NET support). I don't think it is not required. It is better if we find some tools which support both environments. I know this is EJB group, but in reality all big companies are using both environments. I had good experience with NeuVis Architect which initially supported both plateforms. Now after becoming part of IBM, they have drop that support.
  18. Well done alachisoft![ Go to top ]

    Well Done Alachisoft!