What I can't grasp is why people find it 'reasonable' to type in all those attributes and xml tags? Imagine yourself on a system with 50+ tables with on average 10 fields per table. That's at least 500 attributes you have to type in or 500 xml tags, probably
more. And it's very very repetitive. A tool should do that for you. Xml tags are generated easy, attributes are not. I therefore can perfectly understand why Thomas moves towards XML for his tool and I really fail to see why any O/R mapper would use attributes
to specify the mapping: it's an enormous amount of work to get the complete mapping for a bigger system and it is error prone: a tool which generates the mappings from mapping specifications, doesn't make a typo, doesn't forget a mapping, will always specify
all relationships. cklein: Object Spaces will not cut it. .NET needs a foundation for O/R mappers like EJB from MS, not another O/R mapper. (with serious shortcomings, especially when it comes to the lack of an EJB equivalent). Also, OJB.NET might look nice,
I doubt it will ever reach 1.0. Most OS O/R mappers today on .NET are nice, but don't come with a tool that does the work for you. So instead the developer types in tedious amount of lines with sql code, he types in tedious amount of lines of attributes or
xml tags. Both are unnecessary, and illustrate that with a good idea and a good core, you don't have a complete package. It's like calling a C# compiler and notepad an IDE. You can create software with it, the core is excellent (C# compiler) but it doesn't
make you productive. About changing database schemas: I'm with Thomas here: database schemas should only be changed in the abstract model, i.e. the NIAM schema or ORM schema. Which is then used to generate E/R model diagrams which are then used to update the
DDL. _then_ you have a database schema that is based on theory and is correct, which makes developing software targeting that database a breeze. Nevertheless, sometimes a table has to be changed, that's why LLBLGen Pro supports dynamic project refreshment
with schema changes, but frankly I just put it there because I know a lot of people develop software that way, but it shouldn't be necessary. So I don't see the problem when you have to change a few attributes because the database schema changes: it shouldn't
happen a lot. Also that's not the disadvantage of attributes. It's the large amount of time you need to type them all in, error free, that makes them not a very developer-friendly option.
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
Let me comment a little, Frans :-) ::A tool should do that for you. Let me say it like this: an O/R mapper without a designer is a wonderfull timesaver. one WITH a designer is GREAT. I came to this conclusion some time ago, which is why we add a designer to
the EntityBroker 2004. ::I therefore can perfectly understand why Thomas moves towards XML for his tool and I ::really fail to see why any O/R mapper would use attributes to specify the mapping: We do both. I actually prefer the attributes when I work with
the classes. It is much easier - from the librarie's point of view - to get access to data sotred in attibutes than stored in files. But you are right with the "problems" of creating them, so basically in the EntityBroker 2004 I go for an XML file for the
Schema, with a nice editor, and this generates the stub code including attributes. The Attributes DO have advantages, one of them being I can access them easily in my code. ::Object Spaces will not cut it. .NET needs a foundation for O/R mappers like EJB from
MS, ::not another O/R mapper Due to an NDA I can not really say what I Want to say here. Let me just say that MS needs a VISION. Yet another (mediocre, btw. - not a toy, but mediocre) tool is not what we need. We need standards, a paradigm shift away from
datasets and a complete infrastructure. And this without killing sales from guys like me and you and Pragmeatier from a monopolist (yes, there may be lawsuits coming against objectspaces. I can see them). ::So I don't see the problem when you have to change
a few attributes because the database ::schema changes: it shouldn't happen a lot. Also that's not the disadvantage of attributes. ::It's the large amount of time you need to type them all in, error free, that makes them not ::a very developer-friendly option.
My words. BTW - attributes are a little more developer friendly than XML, because the compile rcan ccatch SOME of your typos :-) This is a rare case. If someone runs around changing his database all the time he has serious problems - one of them being he should
not develop software in the first place. For all other people, this is more an "occasional" thing, maybe in batches (I just rewoeked this table " etc., but norhing they do every day and spend a lot of time with. Savings here are marginal. If you change one
property every day in a project and use 4 minutes do to it, how much difference does the recompile do? You spend more time FINDING the data to be changed. I actually find this amazing. So few people get the "relations" right: You spend a TON more time actually
debugging all the business logic which has to be much better than for a dataset approach. It needs to be abuse-safe in business objects, as you do not really know in which context the object will be used in the frontend (as in a dataset driven system you know
exactly what the form does). All changes to the medadata are something that you run very rarely, unless you use an O/R mapper as a replacement for a design tool, and then you have other problems with your architecture.
I can't even fathom your point of view sometimes thona. You make it sound like recompiling a program can never cause more problems than changing a configuration file. Well it can, even with documentation changes. I'm envyous of you for not ever having run into
this problem as I have hundreds of times. It basically involves numerous change requests from the customer being implemented at different dates and those dates changing arbitrarily as related components have issues or unexpected success. Granted, solid change
control procedures would prevent any disaster in this situation, but it is guaranteed that you will not have disaster when you have to change only one file and do not need to recompile, which can cause conflicting dlls to be referenced or not referenced. And
even aside from disaster, the cross compilation problems will at least hold up the move of one particular dll if dates change frequently. The basic principle is simple... touch as little as possible and rely on as little as possible and you will have much
less hassles to worry about in regards to change control. The users may not understand why you can't change one object without affecting another... and why should they? Secondly, and perhaps more importantly, on really large projects with a lot of developers,
it may not be the same person who writes the business object that writes the meta data. Thirdly, and perhaps most importantly, with attributes it would be a real pain to do a global review of mapping. With xml files you can place them all in one centralized
place.
::I can't even fathom your point of view sometimes thona. This is usual given your view of things. Let me explain: ::I'm envyous of you for not ever having run into this problem as I have literally hundreds of ::time. It basically involves numerous change requests
from the customer being ::implemented at different dates and those dates changing arbitrarily as related components ::have issues or unexpected success. Granted, solid change control procedures would ::prevent any disaster in this situation, I translate it
into: "I am not smart enough to actually put regression testing, proper change management and regular practices like source control into proper use and thus have to constantly fight desaster". I mean, you say that you have permanent change requests, do not
deal according to regular development practices (iterative releases of changed functionality, lets say once a week), have no mechanism in place to propritise change requests, do not use your tools property (such as a good version control system) to get things
under control again and - well - then say you can not see my point? Interesting. Thank heaven I have read some ooks some years ago. Let me bet: * You do not use version control softwar in a proper way, meaning: to hold your code AND to identify development
branches. INSTEAD you seem to (and you make a pretty elaborate point into explaining that you do) prefer to struggle with constant change requests: ::It basically involves numerous change requests from the customer being implemented at ::different dates and
those dates changing arbitrarily as related components have issues or ::unexpected success. Hm. do you now concepts such as iterative releases of small changed versions? ::The basic principle is simple... touch as little as possible and rely on as little as
possible and ::you will have much less hassles to worry about in regards to change control. Besides without touching things like your test suits (which you DO maintain, right?) you are basically running a minefiled of functionality you are never SURE is working,
but basically think is working. You should try using software such as NUnit to make regression tests. ::but it is guaranteed that you will not have disaster when you have to change only one file ::and do not need to recompile Can someone hold you liable for
these quarantees? Just asking, because they are very short sighted. There is a LOT that can go wrong when you "just change one file", you know. Actually every programmer should know this. You could make a change that does not REALLY work, and then - boom.
Without a compiler you dont even have a step in between to tell you you did certain stupid things (which a compiler does catch, as opposed to most runtime environments). Like, to give you an example: if we would dump our metadata into an XML file, the "change"
you do COULD be wrong. Now, the attributes - could also be wrong, JUST that you are not supposed to write them, but an editor writes them out, and he eidtor is pretty smart (or: getting better every day at the moment) in cathing errors before it writes out
the data. Typos etc. can really break your neck in a mapper's configuation file. Agreeing with frans, I also dont understand anymore how people could really like configuring mapping information manually. ::Secondly, and perhaps more importantly, on really
large projects with a lot of developers, ::it may not be the same person who writes the business object that writes the meta data. Which is perfect and absolutly fits our next iteratio nof the EntityBroker. The person maintaining the mapping maintains the
schema file and regularly regenerates the stubs, while the person working on the business objects does not even get to see the mappings. What else do you want in terms of separation? ::Thirdly, and perhaps most importantly, with attributes it would be a real
pain to do a global ::review of mapping. With xml files you can place them all in one centralized place. This is totally wrong. Basically, when I dumop all your mapping information into 100 something XML files then tell me where is the overview? This problem
is a non issue - just use the Schema file as overview, or dump a consolidated (i.e. effective) mapping schema into a XML file for further processing. You should not this little extra detail: "a consolidated mapping schema". This is one XML file for all the
business objects you have. Naturally it helps a lot to actually use the Schema Editor and some of the overview forms we currently develop :-) (may I note as the only one - I have never seen anything in a mapping layer that actually does come close to giving
you a good overview). AND - the "overveiw" should really exist insome documentation, to start with :-) Anyhow, you really seem to be a very big fan of non-planning and only ad hoc changes. Naturally you will not be comfortable with anything that is done to
help people using planned development methodologies.
There it is again, thona dictating how his customers use his app. Yes, that's right... I actually work with customers who tell me what they want, not me telling them what they want. God forbid that I want to make a change to one fragment of an enterprise application
without having to recompile the entire application, spend 400 hours planning, and run nunit tests in every environment including production. What does prioritizing have to do with it? Have you ever worked with an actual end product before? No matter how many
nUnit tests you run, there are going to be bugs in an enterprise application, and you're going to have to fix them NOW, and not wait until the next iteration of release. This means either having multiple independent servers in EVERY environment and staging
changes this way, or it means doing some dirty work, because you might be working on a change for that 'next big build' on acceptance but need to push an emergency change through there as well. Apparently you never have worked on mission critical systems where
you have to make a change NOW because otherwise it would be obvious to you that having to recompile an entire app whenever you make a microscopic change is NOT IDEAL. If you don't believe me re-read the dozens of posts from other developers saying the SAME
THING. Also, an OVERVIEW is not the same thing as a REVIEW. Please consult www.m-w.com
Obviously we are not in total agreement here. On one hand there are lucky few like thona who follow strict procedures and methodologies and get paid good enough to justify the extra time spent on these things. On the other hand we are a bunch of unlucky ones
who REALLY REALLY like to follow people like thona - but the puny returns in this sluggish economy will not justify the costs. At the end of the day - if we have a happy customer and the application is solving the problem at hand then we have more or less
achieved our motive. Now coming back to the original topic of the post - can someone share some thoughts/comments about these OR mapping tools: http://sourceforge.net/projects/sisyphuspf http://www.norpheme.com http://www.x-tensive.com/
::On one hand there are lucky few like thona who follow strict procedures and methodologies If it would cost so much time I would not do it. I actually am pretty lazy with these. If does not really cost a lof of time to maintain a partial class etc. diagram
in the back of your thinking, and it does not really cost any time to make some planning upfront. It also does not cost any time to put up test cases - actually a complete methodology of fast programming (extreme programming) is based on unit tests. (with
my problem being: I never found a real way to get unit tests done with databases and O/R mapping layers - I proapbly have to build some support into the mapping layer for "faking commits" or something). Norpheme: third grade toy for the moment - a lot of open
things not solved. Has some potential, but needs a lot of attention the author seems not to put into it. It needs a lot of work to come to current full featured standard and not be just "hard to use". sisyphuspf: not too bad. Definitly not a toy, pretty feature
complete. Main complaints are along the line of what OTOH they must have someone in the design team that makes his deisgns while drunk. Sample: Field Attributes. They have one for every data type. NOW: *if the attribute is on a field/property, I can - yes
- use reflection to get the type. So no need for an attribute. * If I need the attribute, I could use an enaum to define the type. BAD programming. Besdides this, they have potential. But they come - as most offers do - without anything that could be considered
to be a designer. x-tenxive: some interesting features. I really like some ideas they have about handling languages - we work on a CMS on the side, as do our customers, and I have heard requests for handling langauge translated poroperties in the EntityxBroker
for some time, just never came up with a good idea HOW to do it. They have the same "abstract class/properties" mechanism that we jsut abandoned in EntityBroker 2004 (former 2003.1 - we just changed name). Like most there is a ton of marketing garbage on their
page (maybe I should pout some up, too). I like their "Wide range of supported SQL types" - call this "we do everything ADO.NET does and are not so stupid to stop certain types frmo working". They seem to be done along the lines of ObjectSpaces / EntityBroker,
which is a sign of someone with a sound understanding of .NET behind. Their "planned features" show a sign of vision - it is pretty identical with our 2004.1 feature list :-) Sadly they are - as frans said - not ready with a designer yet. I was there once,
too - now I am smarter and have given in into the advantages of actually having a good looking and easy to use designer. I really like (sort of) their idea of multi langauge properties. This is something worth exploroing, although I have rejected their approach
as "too limited" half a year ago. They seem to be too much on the "limited" side, though. Doing a lot automatic can get you into trouble - proposing automatic solutions in a designer is one thing, having the runtime do a stupid decision is another thing. Like:
"DataObjects.NET can automatically upgrade the existing database structures to the new version". This is something I would like to see working in real life without being in a "laboratory environment". They are a wannabe EntityBroker clone in the core, more
limited than our 2003.0 offer (as they seem not to have had customers demanding that they deliver certain features). I would say that t for their price they are a fair deal - if you ignore that the next generation of tools (much easier to use) is just around
the corner. The most interesting feature with all of them is that they lack databinding integration (no, a relation as an IBindingList does NOT cut it, sorry) and integaration with .NET standard error reporting (which we seem to be the only one realizing that
something like this exists). It is sad- this is a nice feature that easily integrates with the ErrorProvider component to mark databound fields that contain ivalid values. And all of the offers you mentioned desperatly lack a designer (I know I once said the
EntityBroker does not need one - I confess, I erred - woring with a Deisgner makes a REAL difference).
Thomas - When can we expect the next version of EB? I guess it will have lot of new features that I am looking for. FransBouma - I tried your LLBLGen Pro and I think it will also fit well in my project but I am surprised that I cannot create a new project with
the demo version and get a real feel of the product. I think your product might be most cost effective but I cannot say with 100% surety because I cannot create a new sample project right now.
::When can we expect the next version of EB? Well, we have changed the name now (from EntityBroker2003.1 to EntityBroker 2004) and a preview is supposed to go out next week. This is basically a beta sans documentation nad with a not polished editor. I am just
fidling around witha a column locking architecture (in case people need it) and we have to make the VS.NET integration part (which is not too hard - we will keep the editor separate, and have the corefunctionality duplicated in the addin). The "real beta"
about one or two weeks later, which we will take to write documentation and get the editor into a MUCH better shape. I would say two weeks from now we are in beta (but anyone with knowledge of the current version or it's docs can work with 2004). The current
samples are already done, so it is not that much work, BUt the documentation is a lot, and we want to make the editor much easier to use (still).
guest_asp: When you release a commercial software product and you want your potential customers to try it out first, you have two options (some others also but those are not that interesting): release a time-limited full featured demo or release a feature crippled
non-timelimited demo. The time-limited demo has an advantage that everything is available. A disadvantage is that there is not that much time to test everyting out. Because an O/R mapper is not something like 'winzip', you have to test it really good before
you can decide that you want to work with it, after all you'll probably will work with it on a number of projects. Another disadvantage of a timelimited demo is that you have to implement some sort of time-limit check. You can do that by creating a new file
in the system32 directory, or do something fuzzy with the registry or similar lame approaches. These do not work very well for the vendor. Another approach is you ask the demo downloader to register himself and send him a new license with a time-limit. This
is a small hurdle for the demo downloader but could work. The biggest disadvantage of time-limited demos is that you as a vendor can't control what the demo downloader tests. This sounds fishy but let me explain this a little bit: during the pas 14 months
or so since LLBLGen 1.x is released and used by tens of thousands of people I learned a very valuable lesson: a lot of people don't know how to set up a database: no FK's defined, no PK's defined, 2 schema's which should have been 1, 2 or even more FK constraints
on 1 non-PK field (!) and so on and so on. When these people try the tool to test the TOOL (!) they end up testing their database design instead of testing the tool. So I opted for the feature-crippled option: no timelimit but you can't create a new project.
This sounds limiting at first, but it really isn't. Northwind is a great testdatabase, because it has almost anything: identity fields, defaults, nullable columns, unique constraints, foreign key constraints, check constraints, relations with self (employee
has a relation with itself, very common), and so on. Thus the far majority of cases you will run into are available in northwind. So by supplying a demo that allowed the user to test the TOOL with a database that has almost anything the demo user will use
himself assures the demo user he is testing the tool, not his database design skills. A question then pops up: but what if the user buys the product, he'll run into problems with his own database!. Probably at first yes. But then he knows it's not the tool,
it's his database, and no matter what: his database has to be correct (that is: without errors :), it's not about design choices). LLBLGen Pro allows him to do that though: it contains logic that will help the user locate errors in the database (bad stored
procedures, tables without keys, fk's defined wrongly etc.). If you really need a time limited license, mail me and I'll mail you a license that is time limited for a week. (the logic is build in, we opted for the crippled-option and see how it goes. we can
change it in the future).
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
FransBouma
Participant
1509 Points
312 Posts
Re: O/R Mapping Tools for .NET
Sep 12, 2003 06:35 AM|LINK
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
thona
Member
20 Points
2923 Posts
Re: O/R Mapping Tools for .NET
Sep 12, 2003 10:42 AM|LINK
Stephen Vaki...
Contributor
2540 Points
508 Posts
Re: O/R Mapping Tools for .NET
Sep 12, 2003 12:59 PM|LINK
thona
Member
20 Points
2923 Posts
Re: O/R Mapping Tools for .NET
Sep 12, 2003 01:33 PM|LINK
Stephen Vaki...
Contributor
2540 Points
508 Posts
Re: O/R Mapping Tools for .NET
Sep 12, 2003 04:36 PM|LINK
quest_asp
Member
45 Points
9 Posts
Re: O/R Mapping Tools for .NET
Sep 12, 2003 05:12 PM|LINK
thona
Member
20 Points
2923 Posts
Re: O/R Mapping Tools for .NET
Sep 12, 2003 08:00 PM|LINK
quest_asp
Member
45 Points
9 Posts
Re: O/R Mapping Tools for .NET
Sep 12, 2003 10:13 PM|LINK
thona
Member
20 Points
2923 Posts
Re: O/R Mapping Tools for .NET
Sep 13, 2003 05:43 AM|LINK
FransBouma
Participant
1509 Points
312 Posts
Re: O/R Mapping Tools for .NET
Sep 13, 2003 08:47 AM|LINK
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)