LinqToUmbraco or Umbraco Interaction Layer (UIL) ?
Hi guys,
I've been testing the new LinqToUmbraco in the 4.1 alpha version and I must say that it is very impresive. The only problem I had is that it looks like the umbraco.Linq.Core dll seems to be missing from http://umbraco.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=21100, so I had to download the project from Codeplex and recompile.
As I understand, UIL and LinqToUmbraco it is basically the same since Aaron first developed the UIL but now he's part of the Core team and he has integrated this feature to Umbraco, but I assume that LinqToUmbraco has improved / changed.
Is it better to work on a stable release such as 4.0.1.2 and use the Umbraco Interaction Layer http://uil.codeplex.com/ or should I wait for the coming 4.1 Beta version and use the LinqToUmbraco?
Well I'm probably the best person to field a response to this :P
I'm not sure what umbraco.Linq.Core wasn't included in that build, but it will definitely be part of the 4.1 beta which will be coming next week.
Although the UIL is the father of LINQ to Umbraco the projects actually had different goals. The UIL was initially a way in which it was easier to programatically perform CRUD operations against Umbraco Document Types, but really it was nothing more than a wrapper for the Document API. LINQ support was included but it was really an after thought and not really well implemented. In fact it completely hammers the database if you try and use it! (I mean REALLY hammers the database). Essentially UIL was designed for back office workings.
Additionally the UIL is no longer an active project (see my post here - http://www.aaron-powell.com/blog/february-2009/uil-v11-release,-and-some-sadness.aspx). Since I joined the core team I've decided to focus my attention to having LINQ to Umbraco become a spiritual successor to the UIL, but really the two projects have very different goals.
LINQ to Umbraco doesn't have any focus on where you're going to be getting your data from, it uses a provider model and that is what specifies where you will be loading data from. v4.1 of Umbraco will be shipping with a default/ example provider called the NodeDataProvider which will allow you to be interacting with data from the Umbraco cache. This means that it's only designed for read access, the API does support full CRUD operations but only if the provider supports it (which the NodeDataProvider doesn't).
Which API you use really comes down to what goals are, if you are wanting CRUD operations then UIL should do what you require, otherwise LINQ to Umbraco will be greata for front of house operations unless you want to create your own provider. But keep in mind that the beta release should not be used in production. We've already got a few things which we know which are going to be adjusted before the RC/ RTM releases are produced (including LINQ to Umbraco).
You can always write your LINQ to Umbraco implementation, the company where I now work did that before I started, Shannon wrote a blog post on how it goes, which can be found here - http://farmcode.org/post/2009/02/24/Linq-to-Umbraco.aspx
Thank you very much for your help. I'm not planning to perform any CRUD operation, so I guess that leaves the UIL out of the game. Also I was very keen of using the LINQ to Umbraco but you are right about I should not be using the beta version in production, so I guess I'll wait till Umbraco Release Candidate.
I had a look to the Source code of your own implementation and I think this is exactly what I need for now. Thanks for sharing the link and congrats for the nice work your doing with LinqToUmbraco.
LinqToUmbraco or Umbraco Interaction Layer (UIL) ?
Hi guys,
I've been testing the new LinqToUmbraco in the 4.1 alpha version and I must say that it is very impresive. The only problem I had is that it looks like the umbraco.Linq.Core dll seems to be missing from http://umbraco.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=21100, so I had to download the project from Codeplex and recompile.
As I understand, UIL and LinqToUmbraco it is basically the same since Aaron first developed the UIL but now he's part of the Core team and he has integrated this feature to Umbraco, but I assume that LinqToUmbraco has improved / changed.
Is it better to work on a stable release such as 4.0.1.2 and use the Umbraco Interaction Layer http://uil.codeplex.com/ or should I wait for the coming 4.1 Beta version and use the LinqToUmbraco?
Thanks
J
Well I'm probably the best person to field a response to this :P
I'm not sure what umbraco.Linq.Core wasn't included in that build, but it will definitely be part of the 4.1 beta which will be coming next week.
Although the UIL is the father of LINQ to Umbraco the projects actually had different goals. The UIL was initially a way in which it was easier to programatically perform CRUD operations against Umbraco Document Types, but really it was nothing more than a wrapper for the Document API. LINQ support was included but it was really an after thought and not really well implemented. In fact it completely hammers the database if you try and use it! (I mean REALLY hammers the database). Essentially UIL was designed for back office workings.
Additionally the UIL is no longer an active project (see my post here - http://www.aaron-powell.com/blog/february-2009/uil-v11-release,-and-some-sadness.aspx). Since I joined the core team I've decided to focus my attention to having LINQ to Umbraco become a spiritual successor to the UIL, but really the two projects have very different goals.
LINQ to Umbraco doesn't have any focus on where you're going to be getting your data from, it uses a provider model and that is what specifies where you will be loading data from. v4.1 of Umbraco will be shipping with a default/ example provider called the NodeDataProvider which will allow you to be interacting with data from the Umbraco cache. This means that it's only designed for read access, the API does support full CRUD operations but only if the provider supports it (which the NodeDataProvider doesn't).
You can 'easily' create your own provider, I did a demo/ POC of this in another blog post - http://www.aaron-powell.com/blog/july-2009/creating-custom-dataproviders-for-linq-to-umbraco.aspx but that was using a very early build of LINQ to Umbraco and will not work with the beta (there have been some structural changes to the API so it wont compile without a bit of tweaking).
Which API you use really comes down to what goals are, if you are wanting CRUD operations then UIL should do what you require, otherwise LINQ to Umbraco will be greata for front of house operations unless you want to create your own provider. But keep in mind that the beta release should not be used in production. We've already got a few things which we know which are going to be adjusted before the RC/ RTM releases are produced (including LINQ to Umbraco).
You can always write your LINQ to Umbraco implementation, the company where I now work did that before I started, Shannon wrote a blog post on how it goes, which can be found here - http://farmcode.org/post/2009/02/24/Linq-to-Umbraco.aspx
Hi Aaron,
Thank you very much for your help. I'm not planning to perform any CRUD operation, so I guess that leaves the UIL out of the game. Also I was very keen of using the LINQ to Umbraco but you are right about I should not be using the beta version in production, so I guess I'll wait till Umbraco Release Candidate.
I had a look to the Source code of your own implementation and I think this is exactly what I need for now. Thanks for sharing the link and congrats for the nice work your doing with LinqToUmbraco.
J
is working on a reply...