FluentData: A New, Lightweight ORM with a Fluent API
- Share
-
- |
Read later
Reading List

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.
FluentData is a new introduction to the micro-ORM family that aims to be more straightforward to use than full ORMs. Introduced this month, it uses a fluent API and supports SQL Server, SQL Azure, Oracle, and MySQL.
According to the creator of FluentData, Lars-Erik Kindblad:
The existing ORMs frameworks on the market such as Entity Framework and NHibernate are overly complex and difficult to learn. The generated SQL from those frameworks are poor due their own abstracted query language and mapping from the database to .NET objects is difficult.FluentData takes a different approach by being a lightweight framework with a simple fluent API that is easy to learn.
Similar to other micro-ORMS, such as Dapper and Massive, FluentData focuses on performance and ease of use, and allows developers to have greater control of SQL rather than relying on the ORM to generate it automatically. It uses SQL to perform selects, inserts, and updates, and also supports the use of stored procedures and transactions. According to the documentation, it can work with any business objects without changes to the existing structure.
Other features of FluentData include:
- Multiple Result Set: return multiple data sets with a single database hit
- Developers can use either strongly-typed or dynamic objects
- Custom Entity Factory for complex objects that require special actions during their creation
- Ability to add support for other databases
FluentData requires .NET 4.0, and supports SQL Server, SQL Azure, SQL Server Compact, and Oracle and MySQL using .NET drivers. For further information, code samples and a free download, visit FluentData on CodePlex.
Rate this Article
- Editor Review
- Chief Editor Action
Hello stranger!
You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think
Hmm.. another one...
by
Roopesh Shenoy
Choice is good, but too much choice is bad.
Re: Hmm.. another one...
by
Lars-Erik Kindblad
FluentData is built on top ADO.NET so it's not reinventing the wheel but rather making it more optimized. It takes the very best from ADO.NET and adds a nice fluent API with some extra features to make it easier and more efficient to use.
Re: Hmm.. another one...
by
Roopesh Shenoy
Re: Hmm.. another one...
by
Lars-Erik Kindblad
Connecting this to your previous question, would using Dapper simplify FluentData in any way? I dont think so, dependencies tend to increase the complexity and add constraints. I might save some lines of code in the beginning, but most Micro ORMS are from a few hundred lines of code to a few thousands, and in FluentData's case most of the code are for making the simple fluent API on top of ADO.NET (which dapper do not have).</product>
Fluentdata
by
Gerardo Gonzalez Cruz
I like it!
by
M Vleth
Re: Hmm.. another one...
by
serge ----
Managing the connection state yourself can be a good thing. This allows people to implement their own connection life cycle mechanisms (pre post processing logic, connection reuse etc). Also, something like Dapper.net integrates with standard infrastructure like system.transactions TransactionScope.
Re: Fluentdata
by
Lars-Erik Kindblad
Re: Hmm.. another one...
by
Jonathan Allen
Build one if you want..
by
Mark N
I can't speak for EF, but NHibernate came from Hibernate. Hibernate started out simple. But it grew because people would say "it can't do X" and the authors realized that the Relational and Object worlds were different and thus the mapping between the two IS complex.
Having used both EF and NHibernate, they are not that tough to use. Although EF can be a pain sometimes because it didn't learn from EJB1/2. The generated SQL is not bad. The issues come in to play when people don't realize that there is a RDMBS, not an ODBMS.
For the record, you CAN use a fluent type API with NHibernate. Having used SQL and HQL for years now, I cannot see how plain SQL can support complex object queries. And that is what you run into when translating objects to tables.
Also, both EF and NH support LINQ so your queries are not in Strings. Not sure if FD supports that, but the examples saw used Strings.
Re: Build one if you want..
by
Lars-Erik Kindblad
Mapping - Mapping from a database to an object oriented structure and vice versa is simple. Just use a simple auto mapper that handles the 1:1 cases, and take a manual approach for the rest through a concrete-not-abstracted-away mapping method. This creates a simple but solid solution that is easy to maintain and extend. And time wise I would say it saves time to take the simple approach cause you don't need to deal with and work around all the constraints that the ORM frameworks forces on you.
"but stop the revisionist history. I can't speak for EF, but NHibernate came from Hibernate. Hibernate started out simple. But it grew because people would say it can't do X"
- if you don't abstract away from SQL then the feature set you need is pretty limited.
Me too mini ORM that needs only .NET 2.0
by
Binoj Antony