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) > >> It's fine if you're just doing CRUD operations. At my job, we do staff > >> 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
