The restriction on not using dynamically generated SQL statements would have
ruled out ObjectSpaces anyway. OS does that.
I'll leave the debating on the best O/R mapper to the others. There will
probably be a lot of response on that.
Alex
--
Alex Thissen
Weblog: http://www.alexthissen.nl
"Ramon Leon" <rl...@insario.com> wrote in message
news:28f19362.04052...@posting.google.com...
> Hi, after recently reading about object spaces being delayed I've
> gotten sick of waiting. So, I want some opinions on what the current
> best OR mapper is for the csharp/sqlserver environment. I don't need
> multi-database access, just SqlServer support. I'd like
> recommendations for "real" OR mappers, that will map my existing
> object model to a database. Too many of the one's I've seen aren't
> really OR mappers, but silly little data access layers.
Academic discussions about what's real and what's not real are great for
debates between people who don't have to do real work, but are really a bit
useless in the real (pun intended) world.
I.e.: what matters is getting your work done, not being the purest developer
on the planet, because being pure doesn't enable you to meet deadlines or
functionality requirements.
O/R mapping is a technique to overcome overhead in your software. That's it.
If a tool decreases the overhead which is related to data-access using OO
development, the tool is 'productive' and thus works. If a DAL generator does
that, it thus works. If a pure O/R mapper does that too, it also works.
However, which one is better is hard to say: perhaps the pure O/R mapper
increases your project development time with 10% because it requires
attributes being applied to all your 600 entity classes you had to write by
hand.
> Also, I'd
> like to know if any of them support doing all their work via
> pre-generated stored procedures. My only restriction, is that I'm not
> allowed to use any product that relies on dynamically generated SQL.
> I don't have a choice here, this restriction is my clients, and I'm
> stuck with it. Anyone have any ideas here? Any products to
> recommend?
You want a pure O/R mapper and not a DAL generator but you want to use
stored procedures?
You are not able to convince your client that how the DML is formatted is
not important, but you are able to convince your client you're using the most
purest O/R mapper on the planet? I think you have set your priorities wrong.
O/R mapping is only succesfully implemented when the SQL is generated
dynamically. Oh, some tools will offer you the ability to bind CRUD
operations on the entities to stored procedures, however that's not the
important aspect: what's important are the filters defined in your code,
eventually spanning multi-entity filters, custom sorters etc. Using stored
procedures for these actions is hard, I don't know of any O/R mapper who
allows that. It would be very counterproductive as well btw, because you have
to pre-design the queries up-front before you start developing the software,
which will result in a lot of queries being thrown out during the process.
Ramon, honestly, drop the I-want-pure-stuff-only thought. It's productivity
that counts. If you can reach a 40% productivity increase with tool A which
is '80%' pure and a 20% productivity increase with tool B which is 100% pure,
you would be stupid if you opt for tool B. But again, if you can't live with
a not-so-pure tool, it's up to you.
Also, about the procs: if you tell your customer that you can save him 30%
on development costs by opting for a tool with Dynamic SQL and you tell that
person that dynamic SQL is not 'unsafe' nor 'slow' or other mythical crap
DBA's try to spread around to keep their own job safe, I'm not that sure your
customer will stick with stored procedures. After all, he's no expert on the
subject otherwise he would have developed the software himself, not?
I've met a lot of people who thought they knew what a pure O/R mapper could
do and should do. When I asked them why they thought that was important most
people couldn't give me 1 reason, they most of the time simply re-state what
they heard. This is sad, since academic discussions about theory are great,
but are not meant for selection criteria in real-world scenario's, as they
often assume a clean-room environment which doesn't match any real-world
scenario at all.
FB
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP
Best Regards
/Mats Helander, Pragmatier
http://www.pragmatier.com - Proven O/R Mapping for the :NET Platform
http://news.pragmatier.com/matshelander/Weblog/ - My weblog
"Frans Bouma [C# MVP]" <perseus.us...@xs4all.nl> wrote in message
news:xn0diotb...@msnews.microsoft.com...
cool, subscribed :)
Frans.
I mean real as in it can use my classes and not force it's own class
design on me. O/R mappers do that... DAL generators don't.
> You want a pure O/R mapper and not a DAL generator but you want to use
> stored procedures?
Again, I don't want any of that... my client corporate policies
mandate it.
>
> You are not able to convince your client that how the DML is formatted is
> not important, but you are able to convince your client you're using the most
> purest O/R mapper on the planet? I think you have set your priorities wrong.
> O/R mapping is only succesfully implemented when the SQL is generated
> dynamically. Oh, some tools will offer you the ability to bind CRUD
> operations on the entities to stored procedures, however that's not the
> important aspect: what's important are the filters defined in your code,
> eventually spanning multi-entity filters, custom sorters etc. Using stored
> procedures for these actions is hard, I don't know of any O/R mapper who
> allows that. It would be very counterproductive as well btw, because you have
> to pre-design the queries up-front before you start developing the software,
> which will result in a lot of queries being thrown out during the process.
>
I know all about the trade off's involved, I've had to build my own
mapper/generator to fullfill these requirements, and it's a pain in
the butt. I was just hoping one of the commerical mappers supported
this, I didn't know for sure, hence my post. I was hoping on using
object spaces, because here in microsoft land, ms software tends to
get approved, despite it's shortcomings.
> Ramon, honestly, drop the I-want-pure-stuff-only thought. It's productivity
> that counts. If you can reach a 40% productivity increase with tool A which
> is '80%' pure and a 20% productivity increase with tool B which is 100% pure,
> you would be stupid if you opt for tool B. But again, if you can't live with
> a not-so-pure tool, it's up to you.
>
You're preaching about pure so much it seems somehow you're offended
by that request. Well it's a valid request and it makes a big
difference to an OO programmer that he's allowed to use his own
classes and not some shit spit out by a code generator that's not
quite what he wants. Hey, I'm all for code generation, I write my own
classes and libraries with my own generator, including a data access
layer and home grown O/R mapper. I know all the issues involved and I
know how hard it is to get right. You need to chill on lecturing
people you don't know, don't come in here bashing my request because
your product doesn't quite fit what I want. Hell I used your first
version to develop a thing or two while I was busy writing my own, but
I don't like your design or the redundacny of the generated code.
Your product worked great, and other than the code, I had no
complaints, but I'm a programmer, and code matters, and I don't need a
lecture from you.
> Also, about the procs: if you tell your customer that you can save him 30%
> on development costs by opting for a tool with Dynamic SQL and you tell that
> person that dynamic SQL is not 'unsafe' nor 'slow' or other mythical crap
> DBA's try to spread around to keep their own job safe, I'm not that sure your
> customer will stick with stored procedures. After all, he's no expert on the
> subject otherwise he would have developed the software himself, not?
>
And please re-read my original message, especially the part about this
being forced on my by the client. The fact is, when someone is
willing to pay you to do something the wrong way.. or not at all,
well, you still got bills to pay. Believe me, I'd love to use dynamic
sql, it'd remove all my headace's, but large corporations don't
exactly negotiate their network policies with tiny little contractors
you know.
Cancelled. Not delayed. Cancelled.
The official word is it is merged with the WinFS file system - I would NOT
call this a dalay.
> gotten sick of waiting. So, I want some opinions on what the current
> best OR mapper is for the csharp/sqlserver environment. I don't need
> multi-database access, just SqlServer support. I'd like
Ours :-)
> recommendations for "real" OR mappers, that will map my existing
> object model to a database. Too many of the one's I've seen aren't
Not ours - we demand control over the object model.
> really OR mappers, but silly little data access layers. Also, I'd
> like to know if any of them support doing all their work via
> pre-generated stored procedures. My only restriction, is that I'm not
None. Spell this: none. You ruled them all out. There are very few that work
with everything through stored procedures. The development paradigms are
porthogonal, you know.
> allowed to use any product that relies on dynamically generated SQL.
> I don't have a choice here, this restriction is my clients, and I'm
> stuck with it. Anyone have any ideas here? Any products to
> recommend?
Yes.
Handcode. Use old LLBGEN (not pro). Not an O/R mapper, but it works nifty
and without problems with stored procedures.
--
Regards
Thomas Tomiczek
THONA Software & Consulting Ltd.
(Microsoft MVP C#/.NET)
(CTO PowerNodes Ltd.)
---
Still waiting for ObjectSpaces? Try the EntityBroker today - more versatile,
more powerfull.
And something in use NOW. for the projects you have to deliver - NOW.
However, at this point, ObjectSpaces has been merged with WinFS API
project. See http://msdn.microsoft.com/data/ for announcement
Hmm, that is a rather nasty restriction isn't it :-) I rather like the way
we can just do things like this:
Imports Granite
<Granite.ObjectDef("People", "PersonID", "KnowledgeCentreID")> _
Public Class Person
Inherits GraniteObject
' ---- PERSISTENT FIELDS ----
<FieldDef()> Private m_Firstname As String
<FieldDef()> Private m_Surname As String
<FieldDef()> Private m_Caller As Boolean
<FieldDef()> Private m_Agent As Boolean
<FieldDef()> Private m_Salutation As Salutation
<FieldDef()> Private m_Gender As Gender
<FieldDef()> Private m_Language As Language
' ---- CHILD OBJECTS ----
<FieldDef(Type:=GetType(Jade.DeliveryPoint))> Private m_DeliveryPoints
As New GraniteCollection
<FieldDef(Type:=GetType(Jade.Queue))> Private m_Queues As New
GraniteCollection
End Class
And that's it to save the object into a database apart from an external tree
structure defining the object heirarchy. The fact that Granite then
generates the
Update [People] Set FirstName=@FirstName, Surname=@Surname (etc) Where
ID=@PersonID
for us is a real saving. I assume the restriction is to do with security
around direct SQL? For the above to work, users have to have UPDATE access
to the tables. Therefore, anyone with a bit of ODBC knowledge can snoop
around changing data outside of the app.
Apart from using sprocs for every update (real tedious during developement),
any other bright ideas?
I thought it would be neat if as well as Windows Authentication against SQL
Server, there was application authentication, i..e only allow an application
that has a specific UID assigned against it to carry out the UPDATE or
whatever. As the UID was probably ever embedded in the source code and
inside the EXE, then it would be reasonably secure. Or better still
public/private key?
At the moment, we're considering adding a checksum type field to every
record that Granite updates when it writes the record. This would at least
highlight when a record had been tampered with. Would slow it down though
and wouldn't help with deletes.
Rob.
I'd take that further - the fact that you read an object tree into memory
based classes gives two other benefits:
o Performance whilst the object is in memory
o Far easier to do some logic operations when you have all the objects to
hand
Okay, so you can actually do point #2 with relational datasets but IMHO it's
not as well encapsulated.
Cheers, Rob.
Assuming your complete "Granite" object is stored in a variable
named "granite", all you need to do to store the object to our
object database is:
db.set(granite);
We take care of everything else for you. Reflection is used to
analyse the type structure, when an object is stored. Changes to
the type structure are taken care of automatically, without
having to reorganise the database.
--
Carl Rosenberger
db4o - database for objects - http://www.db4o.com
"Rob Nicholson" <rob.nicholson@NOSPAM_informed-direct.com> wrote in message news:uqAgKrAR...@tk2msftngp13.phx.gbl...
How do you map class variables to the field in the database? The variable
could be called p_Wibble but the database field could be Wobble. Also, how
do you indicate which class variables aren't stored in the database?
Cheers, Rob.
I've had a quick read of the evaluation guide - the DTB application appears
to do in effect what I'm doing with attributes against the objects
themselves. This is a different way of doing it I guess. I can see the
advantages of quickly generating the source code as well as it's a right
pain when starting a new project when you've got the database design already
during the specification.
I'd read that ObjectSpaces used a different mechanism again for defining the
mapping/tree structure, i.e. to use an XML file. I thought about this and
but came to the conclusion what XML is an overkill (and often is!). Okay, so
using an XML file means you can edit things without having to recompile. But
I decided that the chances of (say) a new field being added without
modification to the associated class was very slim so a recompile was on the
cards anyway.
Don't get the me wrong, I like XML. But seeing it as a silver bullet to
solve all problems is dangerous. I was amused to read the blog about the
move back to richer clients to reduce server load. May I play devils
advocate and suggest that part of the reason is the overhead of parsing XML
backwards and forwards between text and binary :-) Okay, so maybe it's my
8-bit games programming roots that is offended by blatant waste of memory
and CPU cycles...
Cheers, Rob.
Since we supply the database there need to be no mapping.
> The variable
> could be called p_Wibble but the database field could be Wobble.
The field would be called "p_Wibble" in the class and in
the database.
> Also, how
> do you indicate which class variables aren't stored in the database?
We supply a an attribute class "Transient" along with our
engine. You can simply mark a field with this attribute,
and the contained objects will not be stored:
class Foo{
String bar; // persisted
[Transient]
String fly; // not persisted
}
Furthermore we allow users to add their own attribute classes
to mark fields as transient, so they can distribute their code
without our engine also.