Marcin Kuszczak wrote:
Please remember that I am not saying that entities are solution for everything. I am just saying that in many cases (most?) it is sufficient enough to use entities instead objects. Especially when you have to use data in presentation layer.
In my program I needed graph analysis and to make it fast I used objects. But
even in that case I put into these objects simple recordsets from database.
Still no need for domain objects.
True -- it sounds like you could have done most of your work in SQL, if
you were sufficiently masochistic.
My current project involves several thousand classes, each of which has
to be persisted, so I'm obviously not using ORM for that; the database
schema would be unmaintainably huge. I'll be using a database, but only
with very minimal information and then a blob of JSON. A library like
yours would be helpful in this situation.
I implemented only simple static data container which doesn't change
automatically its state after creation and changes done by user doesn't change
automatically database. Changes to database must be implemented using sql
statement like below:
Script script = Update(visitcards).Set(visitcards.name,
"Yeti").Where(Equals(visitcards.id, 5));
In such a case to ensure consistency you need to implement simple consistency
checks using e.g. optimistic locking:
.... .Where(Equals(visitcards.counter, dbmatrix.get(5, visitcards.counter)));
dbmatrix - container keeping data read before from database
visitcards.counter - field incremented on every write to this record
If above statement will not be executed, as where clause will not match any
record, it means that data in database have already changed and data in memory
is inconsistent.
Okay, manually implementing optimistic database concurrency. That only
has to be done in a couple places, so it's reasonable.
I use array of rows. Every column in row is indexed by int (it's hashmap). I
have done quite a bit of data processing on recordsets using virtual columns.
The advantage of such a design that you can mix virtual columns with other
virtual columns and with normal columns. So in one column you can calculate
e.g. id of some row, and in other virtual column use this calculated id to get
real data and process it somehow. It's very powerful concept.
It's also very convenient, especially for gui. Let's take simple combo box.
To fill combo box you usually need one column of recordset. With proper API you
can get one column with simple method call. Then for every item in combo box
you need some additional information. It's easy when it is e.g. only id of
database record, but if you need few columns of different data and some of
these data must be calculated? With my framework it's easy also :-)
Data binding directly to the database. It's an interesting and appealing
concept.
