Extension methods on a poco class in subsonic?

Question

I'm considering switching from fluent nhibernate to subsonic as nhib just seems to have a MASSIVE memory footprint which I'm really not enjoying, but I just want to check how subsonic (the simple repository probably) would cope with:

• adding extra fields to a database: at the moment I can map a dictionary value to a field in the database which is VERY cool, is this possible in subsonic? (or anything similar?)

  FWIW: DynamicComponent(x => x.PropertyBag, GetDynamicComponentPart); where propertybag is a Dictionary.

• many to many relationships

• cascading saves/deletes
• mapping a complex object to an xml or varchar(max) column (seralize it to xml obviously)

Answer 1

* adding extra fields to a database: at the moment I can map a

dictionary value to a field in the database which is VERY cool, is this possible in subsonic? (or anything similar?)

  FWIW: DynamicComponent(x => x.PropertyBag,

GetDynamicComponentPart); where propertybag is a Dictionary.

Adding fields is fairly simple. Just add the field to the table, then re-generate the classes from the T4 template.

You won't get any mapping beyond basic primitive types, though. Certainly not a dictionary in a field.

* many to many relationships

You will have to make custom modifications to the T4 template to get any sort of support for many-to-many tables. SubSonic just treats them like any other table.

I have made such modifications and they are of limited usefulness.

* cascading saves/deletes

Only on the RDBMS side. That is, if you setup foreign key relationships with cascades. SubSonic doesn't do any of this.

* mapping a complex object to an xml or varchar(max) column (seralize

it to xml obviously)

Nope. You get no support like this. There are no extensibility hooks to insert your own type converters.

SubSonic is a completely different field from NHibernate. I would call NHib an ORM, but I would not call SubSonic that. Rob Conery, the author of SubSonic, would call it a query tool.

It is very simplistic, which is its goal and strength (as well as weakness). It assists with querying and modifications in a strongly typed way. It lacks a huge amount of features and configurability/extensibility compared to NHib or even Entity Framework.

I would caution against moving from NHib to SS, especially if you have any amount of functionality implemented in NHibernate already. Not that SS is a bad tool, but it has a lot of restrictions.