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.