Thanks for all your responses. I comment on your questions and ideas below. 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. And 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
you.
Gert Kello:
> 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
reasons:
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 them.
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
{
get
{
return (string) base[FIRSTNAME];
}
set
{
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 business
object will usually have some custom validation code that it can put in that
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
once persisted.
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 greatest
extensibility, and is part of what helps my design support massive databases
(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, but
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 (<same
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 cache
and not recreated.
Jon Watte:
> 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 open
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
Description: S/MIME cryptographic signature
