FluentData: A New, Lightweight ORM with a Fluent API
- Share
-
- |
Read later
My Reading List
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
Submit
Submit
Related Sponsor
Compose makes it simple to deploy production-ready databases in minutes in the cloud or on your own servers.
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
Community comments
Hmm.. another one...
by
Roopesh Shenoy
Posted
Re: Hmm.. another one...
by
Lars-Erik Kindblad
Posted
Re: Hmm.. another one...
by
Roopesh Shenoy
Posted
Re: Hmm.. another one...
by
Lars-Erik Kindblad
Posted
Re: Hmm.. another one...
by
serge ----
Posted
Re: Hmm.. another one...
by
Jonathan Allen
Posted
Fluentdata
by
Gerardo Gonzalez Cruz
Posted
Re: Fluentdata
by
Lars-Erik Kindblad
Posted
I like it!
by
M Vleth
Posted
Build one if you want..
by
Mark N
Posted
Re: Build one if you want..
by
Lars-Erik Kindblad
Posted
Me too mini ORM that needs only .NET 2.0
by
Binoj Antony
Posted
Hmm.. another one...
by
Roopesh Shenoy
Why does everyone want to build their own Micro-ORM? And that too with very little difference? Why not just build-on/extend existing ones?
Choice is good, but too much choice is bad.
Choice is good, but too much choice is bad.
Re: Hmm.. another one...
by
Lars-Erik Kindblad
I don't think there are too many choices around when it comes to Micro ORMs. Sure there are some but most of them are based on different concepts and APIs, e.g. Massive vs FluentData. And take into account that the Micro ORM concept is still unknown to most developers. They are either using a full blown ORM (and failing) or ADO.NET. So I still think there are room for more Micro ORMs.
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.
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
Appreciate the effort Lars, but is it different from Dapper?
Re: Hmm.. another one...
by
Lars-Erik Kindblad
I haven't used Dapper but from what I've seen its a set of non-fluent extension methods for the DbConnection class, which for instance forces you to manage the connection state by yourself. FluentData on the other hand provides a tight fluent API, it manages the connection state for you by opening and closing the connection at the right time also during exceptions. Compared to most other ORMs (not sure about dapper) FluentData supports custom collections, so you can either have the query methods to return a List<Product> or your own ProductCollection. If you have some complex business objects then the creation of these can be customized by overriding the Entity Factory. FluentData also supports builders, so for select queries you want to use SQL since this the best and most optimized query language around. But for insert, update and delete you can use builders to generate the SQL in a fluent and convenient way through the support of automapping from the entity type etc.
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>
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 used various ORM's like Opf3, Sequel, EF 4, DBEntry, and FluentData is exciting to learn thanks for share and FluentData is MIT license :P. Another approach is easy to learn. There is no Sqlite or Postgresql or yes? But choise is really good. Greetings to all.
I like it!
by
M Vleth
I like the fact that FluentData actually focusses on binding and not on trying to masquerade SQL. This really seems like something that actually improves productivity.
Re: Hmm.. another one...
by
serge ----
"I haven't used Dapper but from what I've seen its a set of non-fluent extension methods for the DbConnection class, which for instance forces you to manage the connection state by yourself"
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.
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
Sqllite and Postgresql are currently not supported, but I might add them if there is a demand for it.
Re: Hmm.. another one...
by
Jonathan Allen
When it comes right down to it, a thin wrapper you right yourself is probably going to be better than any pre-packaged ORM, normal or micro. Just like DI frameworks, we are going to keep seeing these pop-up as people try to generalize solutions to inherently application-specific problems.
Build one if you want..
by
Mark N
... 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" 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.
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
Mark, I think its a mistake to abstract away from SQL. It adds alot of of uneeded complexity and forces a heavy feature set for any ORM doing it, and it makes the learning curve steep. For instance there is a book on Entity Framework thats 832 pages long while most Micro ORMs have a single wiki page, and they have the same end result - execute a query and allow for mapping between db data to object or object to db data.
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.
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.
