• dolive <dolive89 sina.com> Nov 16 2008

dolive <dolive89 sina.com> writes:

Christopher Wright дµ½:

 Marcin Kuszczak wrote:
 Christopher Wright wrote:
 
 Aarti_pl wrote:
 ...and this high-level design is IMHO mistake. Especially mapping
 relations from db to objects.

 Well maybe someone will give me examples where domain objects are more
 useful than relations? From my observations presentation layer (GUI) is
 also relational, so I don't see a sense with making conversions:
 relation -> object -> relation.

 I am working on db access framework which makes use of relations rather
 than creating objects. And it makes it in typesafe way...

 BR
 Marcin Kuszczak
 (aarti_pl)


 scheduling software -- I'd kill myself if I had to write the scheduling
 engine or rule violation code in terms of database rows. And that would
 be a major performance issue.


 Well, really I don't get what the problem is here. Could you please elaborate
more?


 Scheduling, you assign people to shifts. That's a many-to-many 
 relationship. If I just had database rows, assigning would be a matter 
 of adding a row. With real objects, I have a set of people associated 
 with each shift. This means it's O(1) to check if someone's assigned 
 rather than O(number of assignments).
 
 There are a lot of things like this. You can use the active record 
 pattern, but that's essentially an implementation detail for ORM.
 
 A good ORM solution will help prevent data inconsistency issues. Let's
 say you need this superfast query in one area but it returns some data
 that you already have. If you manipulated that data in memory already
 and haven't committed it to the database already (because database
 access is slow, so you don't want to be committing everything all the
 time), your application will be in an inconsistent state.


 Yes, probably there are ORM solutions which keeps data consistent . But please
notice that "keeping data consistent" is not a property of ORM itself. It's
just that people implemented something like that in ORM systems. I am sure that
it is possible to make data consistency layer also in relational system. I just
don't want object Person in my program, but instead just row with person's data.


 You want a database interaction layer that will return the same row for 
 multiple queries, assuming that the row has the same primary key.
 
 Joins are an issue with this. You're not updating a row retrieved from a 
 join, but you're getting it from the database, and your in-memory row 
 might be dirty.
 
 Also, touching the database is slow. It requires inter-process
 communication; it requires translating data from the database's internal
 format to whichever format it sends over the wire; it requires
 translating from that intermediate format to something the application
 can handle.


 Sure. But mapping this resulting format into objects is even slower. That's in
fact one of major arguments against ORM.
 
 If you can do your query in memory, that's often going to be
 faster. 


 Again. Queries in memory is not a property of ORM. In fact you make them
always when you iterate specific collection e.g. searching for specific value.


 True, thank you for correcting me.
 
 There's still one problem with doing queries, even if you ignore 
 database access. How are you going to arrange these rows? If you want to 
 do interesting operations, not just CRUD, will it be sufficiently fast 
 to have arrays or sets of rows? And will this be convenient from a 
 programming point of view? If not, you're left with implementing active 
 record yourself.
 
 If you are merely doing CRUD operations, a decent ORM might be able to 
 write your queries and database schema for you. If the result is 
 reasonable, you've saved a fair bit of time. If not, you've wasted a 
 small amount of time.
 
 If you have significant business logic, in my experience, you're better 
 off with ORM.
 
 In general I prefer ORM. At the very least to translate rows into
 objects, and to write basic CRUD queries for me; that keeps my database
 access layer up to date.

 Also, it's a lot faster to write code with ORM than it is to write
 custom SQL. I've heard people saying that if you are writing a custom
 database layer in SQL, you're stealing from your employer. This
 presumes, of course, that you're working in a language with a suitable
 ORM library available.


 Well I think that it is just because that there was a lot of man-power putted
into ORM frameworks. And that was probably just because of philosophical
reasons - not pragmatical. :-)


 So what you're saying is that a lot of strangers put a lot of effort 
 into ORM, and this means that I don't have to do as much work. I'm happy 
 with that.
 
 Please see also my other post about my Db access framework. 
 





conversion ado.net + nHibernate to d£¿
 d need a powerful database project