[Mono-list] Any interest in a new open source project?
Sat, 31 Jul 2004 01:03:03 +0200
Hi! I think you should take a look at hibernate.org. Hibernate is a very
nice framework that I have worked with and it is definitly production ready.
It does support maps, as you ask for, but I'm not sure of what you mean with
also in Hibernate you define your mappings in xml files which eliminates the
need to hardcode column names in your business objects and permits advanced
types of mappings. (with "permit" I mean that you probably want to reduce
the mapping information as you have choosen to put it in the business
It's not a .NET framework but you should certainly be able to borrow some of
their nice features:-)
>From: "Andrew Arnott" <AndrewArnott@byu.edu>
>To: "Mono List" <email@example.com>
>Subject: RE: [Mono-list] Any interest in a new open source project?
>Date: Fri, 30 Jul 2004 10:07:43 -0600
>Thanks for all your responses. I comment on your questions and ideas
>By the way, I didn't mention that my goal is to make this MS .NET designed
>thing work in Mono. It probably already does, I just haven't tried it.
>right now the only code I have that is database platform specific is
>targeted at SQL Server, and a little code written for OleDb. I don't know
>if MySQL falls under OleDb or not.
>This quickly gets off mono topic. I should create a mailing list here
>shortly. If you want to join, send me an email and when I make it I'll add
> > So, could You please share You findings about OPF-s?
> > You might make my life much easier :)
>OPFs that I have looked at fall short in what I need to do for two main
>1) All that I have seen seem to be performance-tuned for small to mid-sized
>projects. I don't know what classifies as a mid-sized project, but I have
>potentially millions of rows in tables with several hundred columns. I
>believe that is beyond mid-sized.
>2) They all seem to tie a property in a class directly to a column in a
>table. In a few of my classes, I have something akin to a Map (name-value
>pairs) that are dynamic at run-time (within certain bounds), so columns in
>the persisted tables may be added or removed, and I don't want v1 through
>v500 properties to store various variables. I'd rather have a map for
>My design is different because it actually brings the business objects
>slightly closer to the data-layer, while still keeping them out of the
>actual data-access code. Every business object class derives from a class
>in Safari Cell. The base class does all the grunt work of SQL code. So,
>for example, if your business object has a property to store the FirstName
>of a person, the simplified class might look like this:
>class Person : Safari.Cell.Row // Row is the class for business objects
> private const string FIRSTNAME = "FirstName"; // column in database
> // ...
> public string FirstName
> return (string) base[FIRSTNAME];
> base[FIRSTNAME] = value;
> // ...
>All the caching, persisting, and some of the validating of the new values
>occur in the base class. I say SOME of the validating because your
>object will usually have some custom validation code that it can put in
>accessor method. In addition to custom code, the base class does the work
>of making sure that a newly assigned string value does not exceed the
>defined size in the SQL table. That way, even though the new value is
>cached in a infinite length string in memory, it will be guaranteed to fit
>By now you see that there is no external mapping of objects to database
>fields. It is built into your business objects. This provides the
>extensibility, and is part of what helps my design support massive
>(both in row count and column count).
>Ole Hyldahl Hansen:
> > I have put some effort into finding a suitable solution but no
> > acceptable free solutions exists (I could not find any...)
>I am probably going to release Safari Cell under the LGPL license. X11 is
>also rolling around in my mind, but I doubt that will do. Ideas?
>Preferences? I'm against GPL because I don't consider that free, as
>obligations come with it.
>Ole, the link you sent is excellent. I am still perusing it. My framework
>does not match that list very closely. Some of that is good, I believe,
>much of it is bad, and I would like to develop this project to fit that
>criteria more completely.
> > the following should hold:
> > DataObject o1 = Lookup (<some primary key>); DataObject o2 = Lookup
>primary key>); Assert (o1 == o2);
>I would more explicitly make your last statement:
>Assert ((object)o1 == (object)o2);
>Since you can override the operator and make two object references that are
>different look the same although they are not.
>In answer to that question, yes, I use a hash table to track objects that
>are read from the database so that repeated requests are read from the
>and not recreated.
> > If you're running a multi-threaded application, and different threads
> > do work as part of different transactions, then it's pretty clear
> > that changes to o1 should NOT be visible in o2, unless the transaction
> > that o1 was viewed as part of commits before you get o2. Transactional
> > semantics require this.
>I agree. That is work yet to be done, but I think it will be fairly easy,
>as you say.
>I believe there is enough interest that I feel justified in making this
>source. My hope is that contributors will make it more cross-platform and
>more cross-database, and get some good design ideas from you all. I have
>never hosted my own open source project before. If you have any
>suggestions, please write.
>To tie this into Mono, I'd like to move into mono being a primary
>development platform, but keep it working on both CLI runtimes.
><< smime.p7s >>
The new MSN 8: smart spam protection and 2 months FREE*