Dapper

[Justin Collum]

Hey Ben, how's Dapper working out for you? I started a thread on SO about evaluating ORMs: http://stackoverflow.com/questions/7574863/what-criteria-should-i-use-to-evaluate-an-orm. We're considering implementing an ORM at Ecos (well we have Linq-to-Sql) and EF came up but was not my favorite. So Dapper is very interesting to me; if it's good enough for SO it's good enough for me. 

[Ben Jones]

Haven't jumped in yet, but should be this weekend. The whole orm thing is new to me so I will be taking it slow, but I am excited to get my feet wet (considering I have looked at jumping into the pool for so long).

EF seems to be this giant thing that tries to do everything for everyone and pleases nobody but demo people. I know it will get there, but I want to try something simple first. The idea that SO uses it, but it being simple is what is appealing for me.

How soon are you looking to make a decision at Ecos?

[Justin Collum]

Oh, we're just rolling it around right now. We have more than a few things to fix, so we're not in any hurry. 

[Ben Jones]

I vaguely remember seeing something way back about you and NHibernate...? Was that just research?

[Justin Collum]

Yeah probably, I know next to nothing about it. 

[Ben Jones]

Oh...and I am totally jealous of your 4500+ points on SO...

[Justin Collum]

Hah hah, get a job at Intel where you wait 2 days for someone to approve the 4 hours worth of changes you are going to make to a site -- then you'll see what you can do with your SO score! 

[Ben Jones]

Ah...I see. Pssshh, closer to my house and I am able to hangout on SO all day?!? Sending my resume now!

Hanselman did a podcast back in April that was on point about these micro ORM's (http://hanselminutes.com/262/the-rise-of-the-micro-orm-with-sam-saffron-and-rob-conery).

About 5 minutes in Rob Conery has a thought that resonates well with me. *paraphrased* - If you are going to work with a Database, SQL is best domain specific language you can have. So having this elaborate ORM that abstracts everything away I think is crap. Plus EF and NHibernate just seems way heavy. Yes, I guess I would use it if I came into a project that already implemented it, but if I am on my own or looking to start something, I will stay away from heavy stuff.

[Justin Collum]

I'm gonna get old-timer here on ya: I remember a time on StackOverflow where I thought it was actually possible for me to catch up to Jon Skeet. Ah, those were the days. 

Re: ORMs: I think of them as abstraction. Abstraction is what we do. The key is to know when to abstract and when to get "closer to the metal" as it were. I can't claim enough experience to be able to say I'm right but that's how I think of this whole abstract/don't-abstract thing that we are constantly dealing with in our field. 

[Mark Knell]

Okay, sweetheart, I have to hang up because my fungus is acting up, and if I don't put some Neosporin on it soon... wait a sec.  What?  WHAT??  Is this thing on?!?

---

From: Justin Collum <jco...@gmail.com>
To: pdxalt...@googlegroups.com
Sent: Wednesday, September 28, 2011 9:40 PM
Subject: Re: [pdxalt.net] Dapper

[Adron Hall]

So what is the usage that you're bringing an ORM to the battle?  Do you need to transactional, atomicity of an RDBMS? If you're open to other methods you could skip the whole ORM and just go straight to a nice clean MongoDB or some such. Then all you have to do is manage your model instead of fiddle with a bunch of ORM pixie unicorn magic.

It may be easier, it may be massively more difficult. Just throwing additional ideas into the fire.  :)

-Adron

--
Adron B Hall

Tech: http://compositecode.com
Transit:  http://transitsleuth.com
Twitter: http://www.twitter.com/adron

[Justin Collum]

I'd definitely be open to that but there are people on the team who wouldn't. They may have a good reason too: our database does have a lot of financial data in it so maybe a NoSql solution isn't the best idea. It seems like the "eventual consistency" of a NoSql would sink it. I could be totally wrong here on both counts -- don't know enough about either topic to say yes or no definitively.

Let me put it this way: we've got more than a few typed datasets kicking around our apps. So just going from that to an ORM would be a huge step. But a paradigm shift from relational to document would be a very hard sell.  

[Adron Hall]

Very, very large financial institutions use MongoDB already.  Just sayin'.  ;)

But I digress, if you get resistance ya gotta pick the fight or choose to fight another day.  Sometimes it is better to go RDBMS even if it is a ton more work.  Usually when the ORMs come out one is on the verge of that - which is why I bring it up.

As for eventual consistency, that isn't inherent to a NoSQL Solution.  That's a single characteristic of a type of NoSQL Data Store... thus one of the problems of the NoSQL Name, sometimes it has SQL, sometimes it doesn't, but overall the one thing it doesnt' say is exactly what it is.

As for ORMs, I'd still shy away from Entity Framework if you're a heavy testing shop or if any of the data you handle is actually somewhat complex (i.e. you have more than 2-3 tables). Stick to LLBLGen (if for any reason, because Frans Bouma is really smart and super helpful) or NHibernate (because it is probably the most supported ORM in the world right now). But in the end, I must admit a preference to stay away from much ORM at all, I am more than sold on the simple and robust capabilities of MongoDB or Couchbase and many of the other options. Especially for fast paced dev or prototyping. Nothing beats removing the whole ORM + SQL + RDBMS overhead for getting things done.  

Just my 2 cents. 

-Adron

[Justin Collum]

Another argument in favor of NoSQL that I've heard: much easier to version. In essence every version is just a script to bring old data up to speed with new data, at least that's the way I understand it. Versioning a relational db is a pain. And then you have to get it to deploy correctly blah blah.  

[Tom Denny]

I’ve used the Entity Framework for a few projects.  I agree that there are better ORM’s out there unless you have a compelling reason to use it.  I happened to be using it for Silverlight and RIA which I think was a compelling reason.

 

Aside from the performance issues, I often ran in to problems such as updatable views not being supported (without hacking up the auto-generated files and making views look like tables).  When I first started using it my include (joins) caused the generated SQL to be absolutely horrendous.  I didn’t know this until I noticed it with SQL Profiler.  I wish I saved the auto-generated SQL.  I’m certain it would make Adron’s eyes bleed.  Take-away from this was that learning EF enough for production-level work is a bit of a learning curve.  Keeping everything in sync was also fairly time consuming although EF continues to improve in this area. 

 

-Tom

[Justin Collum]

Tom were you using EF 3.5? 

[Troy Howard]

Unless you're doing something very esoteric, I've found LinqToSQL to
be enough. You can also just extend the partial classes to do whatever
you need to if you are doing something a bit trickier.

That said, I'm fairly certain that I want to avoid using SQL databases
for end user products ever again. They are a nightmare. Adron said it
perfectly "Nothing beats removing the whole ORM + SQL + RDBMS overhead
for getting things done. ".

Generally speaking, avoid layers of abstraction... Really.

Especially ones that hide bad technology. Remove the bad technology.

Thanks,
Troy

[Tom Denny]

I think I started on 3.5 but upgraded to 4.

[Justin Collum]

If we were avoiding layers of abstraction wouldn't ADO.NET be perfectly adequate for everything? Going back to the days of "I need 4 procs for each table in my database (CRUD)" isn't what I want to do. Abstraction is my friend. I think it's important to be able to **judiciously override the abstraction and do it the old fashioned way**. The rest of the time, abstraction suits me fine. Abstraction = productivity. 

[Lee Harding]

I'm kind of a conservative, keep it simple kind of guy (just ask the people I work with), but I have to chime in here about EF.  I end up with much less code in projects that use EF.  And, for the most part, I find what EF does relatively clear cut and easy to understand.

Getting spatial types support is late, and sub-optimal (I hope .Net 5 includes a libraries-wide set of simple geometry types) but still allows me to improve performance while removing code.  I can't ask for more than that.

Sent from my Windows Phone

---

From: Ben Jones
Sent: 9/28/2011 6:58 PM

To: pdxalt...@googlegroups.com
Subject: Re: [pdxalt.net] Dapper

[Lee Harding]

If we're avoiding layers of abstraction, let's all  implement the wire protocol.  Heck, I've written my share of listeners on port 80 but I'm unlikely to do so again.  Good libraries (easy to use right, hard to use wrong, and extensible) make creating software a joy, poor ones make it a job.  EF is all of those things to me, in my admittedly flawed view.

[Adron Hall]

Versioning an RDBMS isn't difficult at all. It's just difficult in .NET because most of the tools for it don't really fill the void. Versioning RDBMSs in Rails is crazy simple. Basically you maintain your model, that's it. Much closer to versioning beauty as it is with NoSQL solutions like MongoDB.

Another idea, that you may want to try if you want the beauty of NoSQL but still what RDBMS/SQL Backend, check out SisoDB. Crazy it is, I almost forgot that one. It's freaking AWESOME! It manages versioning and all that... of course, gotta stick to a good open close principle (which is really easy), but overall...  anyway, I could go on about how cool it is.  Check it out for yourself:  http://www.sisodb.com/

Skip the ORM, go with SisoDB.  ;)

I may even be able to bring some production code I'm building right now that uses SisoDB + SQL Server CE + other cool little bits.

-Adron

[Troy Howard]

Well, I would go further than that. The old days you described were
definitely the bad old days.

IMO SQL (the intermediary DSL for data access) itself is a pointless
layer of abstraction. If you are using SQL, then stored procedures
should be used *very* sparingly and only in specific circumstances.
Especially not for basics like CRUD operations.

The real issue is that SQL itself creates too great an impedance
mismatch between modern programming techniques and the data model. You
want to reduce code? Reduce the impedance mismatch between your
programming language and your data store. Simplify the chain of
operations and remove layers of abstraction.

That's how you achieve real flexibility and the ability to say "yes"
to any user request. We tend to say "no" when something is "too much
trouble to change", and usually the list of reasons relates directly
to the arduous task of manipulating all those layers of abstraction to
have a new structure or behaviour.

WRT to debugging and code complexity, burying things in libraries
doesn't really improve matters much. Just because you didn't type the
lines of code doesn't mean they aren't there...

For performance critical applications, consider using structs,
protobuf, and a document database, or a simple B+Tree that indexes a
blob store. If you start with that as a basis of your architecture,
you'll find that you can adapt your programming techniques to make
that "just work" with far less code, and far less to debug.

Obviously that's a lot of engineering overhead for a web app, which is
why there is a very similar chain available in systems like MongoDB.

Doing the typical stack of:
Domain Object
Third Party ORM
DTO (untyped array)
SQL
Database (often very quirky)

... is the most layers of abstraction with the least benefits.

With MongoDB:
Domain Object
DTO (BSON)
Database

You can decorate your class to automate serialization, and then you're
literally just passing your domain object to the mongodb client and
getting them back from it (it will perform the
seralization/deserialization to/form BSON for you). It's dead simple,
and extremely flexible, and you end up with exactly the same
experience from the application code as the ORM/SQL stack, with WAY
less complexity overhead and maintenance to deal with.

-T

[Lee Harding]

My cynical take on decisions of "platform/technology" generally boil down to a matter of fancy and the question "how do I want to fail?"  There are many interesting ways to fail, and while I've enjoyed several my appetite for it is yet unslaked.  

So, to DB or not DB? I find it amusing that browsers will soon get fopen().  My-oh-my how what was old is new again, so implementing balanced R-trees in Javascript is perhaps a reasonable choice. 

Or, if your problem fits within  constraints like "fields relevant to the atomic operation are in the same document" then maybe MongoDB is an option.  I work on one such project now.  But, most of the time, I live in this sad world where data is a general graph, and real operations are messy and consistency is a must. 

[Adron Hall]

MongoDB. Sooooo freakin' tasty.  :)

I do like Lee's poetic statement of old and new and new being old again.

-Adron

On Thu, Sep 29, 2011 at 1:17 PM, Troy Howard <thow...@gmail.com> wrote:

[Justin Collum]

I re-read this thread today. Much intelligence was displayed all around -- well done gents. 

In the meantime (actually shortly after this thread concluded) I built a web app using Rails and MongoDB. I have to agree with the NoSQL folks: jettisoning your RDBMS is really the way to go. I *never* had to think about my database while I was developing that app, even though I was constantly changing (or even gutting) my Models. I rarely even had to access the database directly -- I could just talk to the Models and write Ruby scripts to update them if needed. I never really even got to take advantage of Rails's db migration abilities because you just don't need to deal with it in the NoSQL world, near as I can tell. MongoDB will be my go-to choice for green-field apps in the future. Unfortunately I'm working at a place where there is a large and old and DBA-supported RDBMS in place. Snowball's chance of working with Mongo on a daily basis. 

I'll also say that Mongo shows up very rarely in job requests in the .NET community -- spent 4 months looking (usually only just barely) for a new job recently and I only saw Mongo come up in some devops positions. There's a whole ecosystem of things that help you get around the pain of object-relational impedance mismatch so there's plenty of impetus to not change. I'm feeling like the .NET world is the last to get the cool gear. 

One last thing: most of the startups in this town are not going with .NET. Maybe it's always been that way. I strongly suspect Node and Mongo are the current picks for tech in a typical startup. 

[Lee Harding]

I know at four successful local startups that use .Net exclusively.  Three of them use RDBMS and the other is using s3 for blob storage.  Just another POV.

Sent from my Windows Phone

---

From: Justin Collum
Sent: 4/13/2012 1:12 PM

To: pdxalt...@googlegroups.com
Subject: Re: [pdxalt.net] Dapper

[Adron Hall]

You'll see that continue. .NET is not gaining any steam in the startup world. The irony is that it is growing, a small bit, by taking over legacy Java Applications.

The new movements, especially in startups are Node.js, Ruby on Rails, and of course the stalwart PHP. These make up, at minimum, about 95% of the startups out there. Microsoft has tried desperately to stem this flow, but no luck. Which then leads us to the fact that...

Microsoft is continuing to push and support .NET for Enterprise, because they won't change for another decade probably. MS will have to get to end of life support and then 5 years after that they might catch up.

What Microsoft has started to do, because they've finally realize that there are two ways to get startup devs.

1. Be NOT Microsoft. So they've started the open source software efforts and gotten involved that way.

2. Use things in Azure that isn't Microsoft. This includes things like Ruby on Rails, Node.js (which has a great team at Microsoft behind it), and of course PHP.

Microsoft is finally starting to find some traction since they've given up on trying to force .NET and they're licensing models on everyone. Their last hope in the startup world is by actually joining the startup world. I'm starting to think they may actually be successful at this effort, but not in a huge way. Windows Azure still hasn't touched on anything close to what Rackspace or AWS has been running.

We'll get to see how they fair against the competition, so far it has been uphill for sure.

Just observations from the battle front... cheers!

-Adron

--

Adron B Hall

Tech Blog: http://compositecode.com

About Me: http://compositecode.com/about

Twitter: http://www.twitter.com/adron

[Todd Behunin]

How much .Net development does Portland Startup Weekend typically
have? I've never been there but am considering attending. But like you
said, it feels like startups typically go the open source (free) way..

Todd

> > On Thu, Sep 29, 2011 at 2:54 PM, Adron Hall <adronh...@gmail.com> wrote:
>
> >> MongoDB. Sooooo freakin' tasty.  :)
>
> --

> *Adron B Hall*
> *Tech Blog*:http://compositecode.com
>
> *About Me*:http://compositecode.com/about
> *Twitter*:http://www.twitter.com/adron

[Adron Hall]

I was the only person that built a ASP.NET MVC Application last time. Everyone else was Ruby on Rails. Just a lot less resistance in general and the knowledge base is vastly bigger around RoR.

I'll bet people will show up and start using Node.js + Express.js these days too. Talk about zero barrier to get running and coding. This is personally my choice these days for a fast dev prototype site. Ya really can't beat Node.js + Express.js + Jade (view engine) for this. Minimal work and maximum return.

As for .NET though, if you show up, and you want to join a team you'd still be able to get away with building a whole site in .NET - the participants are general biz heavy so you'd get your choice of platform to build on.

-Adron