Parent-Child data in ASP.NET C#

DanF · 25 Oct 2011 at 14:21

Yep pretty much, it's moving some of your query and business logic in to your code base. You use a query language like linq or queryover which get's converted in to t-sql by nHiberante at runtime. This means you can ditch your sprocs in most cases but yes you need to release code to fix any mistakes (you are testing right!

).

DanF · 25 Oct 2011 at 14:43

We use queryover way more than linq, it's almost as simple to use but it's also easier for nHibernate to convert in to t-sql. The linq provider only covers something like 90% of the features of nHibernate.

We use attributes like this

Code:

        [DomainSignature]
        [NotNullNotEmpty, Length(Max = Constants.Length.MaxUserName)]
        [NoProfanity]
        public virtual string Username { get; set; }

This is in the command side that deals with inserts/updates and deletes, the validation mirrors biz logic. Our query side has no validation attributes as they can never get persisted back.

You can also use the [DomainSignature] attribute in sharparch which is used in an overriden equality check which nHibernate uses for entity equality.

Dj_Jestar · 25 Oct 2011 at 14:59

Finally; someone else using CQRS.. nice.

Decorators are nasty. I'd rather my domain classes were persistence ignorant and not dependent on the data accessor, which is why we use Fluent NHib and in the rare cases where Fluent won't hack it (i.e. we've found a bug in Fluent that they haven't fixed yet), raw HBM files.

DanF · 25 Oct 2011 at 15:00

Oh the stats for our slowest query, it was a simple 10 column table with id mapped to one object so no joins etc. The query was returning all records in the table, 120,000 of them

this was then cached in memory on first use.

nHibernate averaged 20 seconds to run this, a std sproc/datareader approach took 200ms. nHibernate is doing a lot of stuff in the back end making it not that good for big queries.

DanF · 25 Oct 2011 at 15:05

Dj_Jestar said:
Decorators are nasty. I'd rather my domain classes were persistence ignorant and not dependent on the data accessor, which is why we use Fluent NHib and in the rare cases where Fluent won't hack it (i.e. we've found a bug in Fluent that they haven't fixed yet), raw HBM files.

yeah these are nHibernate.Validator and sharparch attributes, they are specific to nHibernate but not the datasource. They're usually doing simple things like length, nonull, regex style validation meaning porting them would be pretty trivial.

I've love to replace nHibernate with a micro-orm on the query side but our DBA's would argue we should use sprocs instead then all the old arguments and time issues kick back in. It's so annoying waiting for a dba to pick up some work.

Dj_Jestar · 25 Oct 2011 at 15:05

sproc's are always quicker than remote queries. Compiled and optimised once when you create the sproc, innit. Remote queries are compiled every time you run them (I'm ignoring query caching atm.)

A better comparison is a raw remote query and data-reader vs nhib.

DanF · 25 Oct 2011 at 15:09

Well petapoco or t-sql in the query side is pretty much identical to the sproc as the query plan has to be made and cached anyway. The actual call for data was just as quick with nHibernate (we can see this by taking the actual t-sql in nhprof and running it) but what takes the time is creating the objects. It's simply that slow for some reason

When using it in a command style side this is never really an issue as almost all the work is to single records with maybe a few joins, nothing updates that many rows from our app.