Open discussion on ORMs

[dhtmlgod]

@Serenarules

If the doc-db takes off, I very well could see an end to the ORM movement.

And ORM is a compromised solution to a complex problem and has always been a stop gap. The issue was the impedance mismatch between objects and relational data. No RDBMS, not ORM.

@Serenarules

You’d still need a way to access one via code, and this would result in some sort of orm.

No relational data, no ORM, think about what ORM stands for Your object is persisted as is, no mapping in the ORM sense is requried. It’s all straight seralization.

@Serenarules

The only problem I could foresee is in having records of different types and lengths within a given set. It would make it very hard, if not impossible, to code since generic collections need a specific type

I don’t get this

[willthiswork]

No relational data, no ORM, think about what ORM stands for Your object is persisted as is, no mapping in the ORM sense is requried. It’s all straight seralization.

Apparently not everyone agrees with you on this topic.

http://www.doctrine-project.org/blog/doctrine-mongodb-object-document-mapper

http://www.doctrine-project.org/projects/mongodb_odm/1.0/docs/reference/introduction/en#introduction

Me can’t decide wheter you are right or wrong

[dhtmlgod]

A mapper may well be part of the ODB solution but that does not make it an ORM. the Mapper pattern is a well known pattern that != ORM

[Serenarules]

@dhtmlgod

I personally hate returning IQueryable from a repository! It lets connected queries bleed out, your breaking seams and can hinder testing. Unfortunately, I lost the argument in work and our work framework lets you do it but it’s still BAD

You are right about the bleed, but I choose to do it this way for the very reason below.

I hate it when you need to add stuff for extra functionality when you need it. Like when I want to play 2 player on the PS3, I need an extra controller. So instead I play on my own. Or when I might want to use EF, I need another assembly, remember LINQ is another assembly reference, it just happens to be in the GAC.

On the topic of query bleed, I return IQueryable in the repository so that services can fine tune the results before sql execution without having to refactor in a new repository method. I fully realise the impact on testing, and am comfortable with it. That is not to say it is a great solution for all.

On the topic of external libraries, I am ok with things in the GAC that come with the stock .NET library because I can count on anybody who has the right version having the right libraries. I cannot count on everybody having a non MS library though. This is a bit of a nitpick, but that’s me. I really don’t like shipping product-licence.xml files for each thing I include in my bin folder. The cleaner the bin folder the better. It’s an OCD thing.

[Serenarules]

@dhtmlgod

I don’t get this

In XML you can have child elements of different types, and with different attributes, etc.

How would such a mixture be coded in a typed way? List<X> would try to make everything an X. But what if they aren’t all X?

Or are we going to assuming that we won’t pushing xml that far, and stick to single type collections?

[dhtmlgod]

@Serenarules

In XML you can have child elements of different types, and with different attributes, etc.

How would such a mixture be coded in a typed way? List<X> would try to make everything an X. But what if they aren’t all X?

Or are we going to assuming that we won’t pushing xml that far, and stick to single type collections?

I get what you mean, so an item within List<X> could be class derived from X. Honestly, I haven’t look at ODB’s at all, so I’m not too sure. I’m going to make an assumption that this is possibly not an issue. This is based on my gut feeling and assuming that not being able to support polymorphic collections would be a show stopping bug. I could very well be wrong tho </disclaimer>

[dhtmlgod]

@Serenarules

On the topic of query bleed, I return IQueryable in the repository so that services can fine tune the results before sql execution without having to refactor in a new repository method. I fully realise the impact on testing, and am comfortable with it. That is not to say it is a great solution for all.

It has it’s pros and cons, and we use it in our team in our internal framework. Which I’m responsible for, so its stings, haha. We use a single repository with a Query model pattern.

@Serenarules

On the topic of external libraries, I am ok with things in the GAC that come with the stock .NET library because I can count on anybody who has the right version having the right libraries. I cannot count on everybody having a non MS library though. This is a bit of a nitpick, but that’s me. I really don’t like shipping product-licence.xml files for each thing I include in my bin folder. The cleaner the bin folder the better. It’s an OCD thing.

I primarily do web development, so worrying about people not having assemblies is not a problem. When I’ve done desktop development, its usually part of the package anyway, and have use ILMerge a few times to reduce assembly file count.

Only time I have issues with external dependencies is in Silverlight apps (file size concerns), but I try and keep the actual Silverlight as simple as possible and move as much out of it as possible. Even have to justify using Castle within Silverlight, generally use a simple hand rolled IoC instead

[wwb_99]

The only nosql database I’ve got appreciable seat time with is RavenDb. And you can definitely do polymorphic collections there if you know how to subvert things.

In any case, please stop comparing whatever you might have done with xml serialzation to what folks are doing in the nosql space – there is a lot more to it than just serializing stuff out to something not relational.