DAL to generate SQL in .NET (constructing queries for user defined models)

Question

In most cases, classes are known beforehand (eg Customer, Order); they're described for ORMs (eg Entity Framework, LINQ to SQL, NHibernate, BLToolkit) using visual designers, attributes in code or configuration files. When you need to use objects of class Customer, for example, you can write strongly-typed queries like this:

db.Customers
  .Where(c => c.FirstName == "John")
  .Select(c => new { c.Id, c.LastName })
  .GroupBy(c => c.Id)

However, in my application, input data will be processed into models which are defined by users at runtime. Users will be able to add and remove properties, therefore I cannot define models in the code. The idea that this will require manually generating string SQL queries horrifies me. I'd like to be able to write code like this:

db.Tables["Customers"]
  .Where("c.FirstName = :FirstName")
  .Select(new[] { "c.Id", "c.LastName" })
  .GroupBy("c.Id")
  .Param(":FirstName", "John")

(Just example invented syntax.)

Question: is there a library for .NET which helps to construct complex SQL queries without defining models in the code first?

PS Looks like libraries like this exist, just not for .NET. I'd love to see something like SQLAlchemy, Ruby on Rails ActiveRecord, PHP Yii ActiveRecord, Django Models etc.

Answer 1

Rob Conery's massive may be helpful to you. It's a lightweight, dynamic DAL that has the ad-hoc capabilities you're looking for while still giving you some of the benefits of a DAL.

Because it's dynamic it doesn't give you compile-time checking or some of the other benefits of it]s bigger brothers, but it's a very handy little tool that straddles the space between a full DAL and raw SQL.

Answer 2

You ARE in a lot of pain now - this generally is seen as an anti pattern. It actually is, but sometimes it is required (and you may just have one of those apps). The bad news is - no support from any ORM etc.

Most ORM can generate a model from the database, but that is a "development time" operation, so it is not possible to sensibly use when for example your data model is totally unfived. THAT SAID - I am not sure how such an applicaiton would even work.

I am not aware of any application for this - there are two extremes basically: SQL as string, which is generally seen as bad from anyone with a clue, and strong typed objects. Your app falls right in between, from the requirements, and that is something that I think has no support.

One problem you face is that LINQ is - a compile time checked operation, That is soled as hugh advantage, but now it bites you. You POSSIBLY could work by having an "Entity" object as base class that is DYNAMIC, then take it from there (because the compiler will not complain about anything on a dynamic object). Theoretically this could allow you to construct an object query integation for LINQ without compile time checking, but again - no such thing exists IIRC due to lack of "common usage scenarios". I would choke on no compile time checking, for example.

Answer 3

Solution to the problem: Simple.Data by Mark Rendle . It allows to write code like this without defining any classes or properties:

Database.Open().Users.FindAllByEmail(email).FirstOrDefault()

(It was mentioned in the description of the Rob Conery's massive library.)