Does anyone has experience with plinqo 4?
what are the benefits vs EF 4?
A good answer to this is on the PLINQO site itself
http://www.plinqo.com/why-plinqo.ashx
I looked at EF, NHibernate and Subsonic and finally rested with PLINQO as it seems to have the best bits of all the ORMS without too much of the bloat. Plus sitting on top of LINQ2SQL its pretty fast.
You can only really judge this by trying it yourself but I would save yourself some time and try PLINQO before EF.
Yes, we use PLINQ, it's Extremley good and provides out of the box support for ADO.NET Data Services and WCF Data Contracts.
PLINQO has better serialization across the wire options as well.
Related
We are considering moving from Entity Framework to PLINQO L2S. EF has proven to be quite difficult for us to manage in an MVC3 application. I would agree there are areas of our application that can be improved, but overall, EF may not have been the best choice for us.
I am curious to know, recently, if anyone has moved form EF to PLINQO L2S? I have read many posts from back in 2010, but EF was a much different animal then. i am not interested in PLINQO for EF.
We ended up evaluating PLINQO and found there were bugs trying to emulate our model generated by Entity Framework. It was not an issue with how EF generated the database, but rather an issue with PLINQO appending numbers to collection entities. There was too much clean up for us to consider using PLINQO. It has some great features, but the generation caused us issues
We removed our DTO layer and decided to go with pure entities. The performance increase was huge. We tried several mapping libraries and even created our own direct mapping solution, but the cost in performance was too great.
EF 4.1 CodeFirst looks great. It works and sells wonderfuly with basic examples that have one or two joins, but what about larger applications? Did anybody work on a large application where domain and data access layers were implemented with EF 4.1 code first? Did it work? Was it as easy and smooth as examples on asp.net site? I'm mainly working on MVC applications, where there is no change tracking. So far I have been using LINQ-to-SQL, which worked well with some extra mapping code.
Thank you
I'm in the later stages of developing a web application that is fairly complex with EF 4.1 CodeFirst (well its more complex than most examples). I don't pretend to be an expert on code first so others may have different opinions.
I used a domain driven approach along with the repository pattern. The database created by code first worked well though I had to manually optimize the database and add indexes etc. Did have an issue bolting on mvc-profiler but nothing drastic.
There was a learning curve but I reckon that was more down to my lack of knowledge about code-first than anything intrinsically difficult about it. When we started developing the app the ability to recreate a db and seed it sped things up at the start. Though we have disabled that now and any db changes are made manually and the code is updated.
So for me code first worked well, I like this approach for new applications and it wasnt too difficult to get up and running (lots of reading up).
When Linq-to-Sql was first released, I used it quite a lot for small and medium sized projects where a true multi-tier architecture wasn't required.
NHibernate, Small Middleware, Overkill
Where I work, we now almost exclusively use NHibernate for true Domain Driven development.
I'm working on a small temporary (a lifetime of probably a year, maybe less) middleware component where NHibernate feels slightly overkill in terms of configuration and keeping the entities up to date. Especially because I haven't got any control over the DB, it sometimes changes, and it's a little bit "legacy".
Some changes were recently made to the DB, and the NHibernate mappings are not very complete.
Linq-to-Sql? Or EF?
I thought it might be easier just to rip out the IRepository implementation I have and replace it with a Linq-to-Sql implementation. Then I can just use lambdas for my simple queries, and just drag and drop the tables in.
RAD But Dead?
In this scenario the RAD elements of Linq-to-Sql make sense. But it's essentially old technology. Should I not use it? I've never used the Entity Framework. Should I use that, is it as easy and quick to use?
cheers
Is it still OK to use Linq-to-sql?
Yes. It is OK to use any technology which allows you delivering the product in time, with required functionality and quality. You can still find projects using ASP, ADO, VB6. One reason why Microsoft technologies have very hard time in many international corporations is that their products have very short lifetime. Linq-to-sql was on the market less then 2 years and was deprecated by Microsoft but companies / community argued about that and Microsoft changed their strategy little bit. Linq-to-sql doesn't have new features but it is still supported and a fully functional technology.
Will Linq-to-sql or EF solve your problems?
It depends. Perhaps yes and perhaps no. Don't believe to marketing announcements about RAD. Sometimes I feel that people think that RAD is about designer. No. Tools supporting RAD are about well defined API which is easy to understand, easy to use and doesn't contain unexpected behavior (Principle of least surprise) - you will use the API to quickly prototype the application but it still requires understanding and practice. NHibernate's mapping is still prototyping when you compare it with manually doing whole data access. We can even follow the basic rule of good framework: Easy things are easy to do and hard things are possible. That is something that NHibernate accomplish much better then EF or Linq-to-sql.
If you know NHibernate but you don't have any real world experience with EF or Linq-to-sql, you can be sure that neither Linq-to-sql or EF will increase your productivity in first one or two projects where you use it. If you don't have too much experience with NHibernate changing to EF or Linq-to-sql will probably don't cause temporary lose of productivity.
I also don't think that EF or Linq-to-sql will generally help you in situations where database changes. As I remember Linq-to-sql designer doesn't have update mapping functionality at all and because of that it is very often used completely without designer so you must still manually modify mapping. EF's updating model from database can be helpful here but it is not a silver bullet. Some updates can require manual modification of EDMX file (huge XML).
At last be aware that NHibernate's mapping features are much more powerful especially when working with legacy databases. Linq-to-sql's mapping features are very limited, it is mostly 1:1 mapping of tables to classes with some exceptions (basic TPH inheritance). EF offers more complex mapping features but it somehow expects a correct design of the database.
If you (and your coworkers) are comfortable with NHibernate, then it should be just as RAD as Linq to SQL. There's no reason not to use L2S as long as you understand it's not going to get much in the way of updates and improvements from Microsoft, but in my experience if you know how to use both frameworks already, no need in re-doing the work just because L2S might be a little more RAD
Some good discussion on NHibernate vs L2S/EF
Entity Framework vs LINQ to SQL
MS Entity Framework VS NHibernate and its derived contribs (FluentNHibernate, Linq for NHibernate)
in your specific case, you should go with technology you are most comfortable with. Though Linq2Sql is relatively straight forward - and build right into the language - it does have a slight learning curve and its own set of gotchas!
So far I did not like EF. Although I liked the tools and how easy it was to create certain types of mappings and relations, Other types were a pain and the Linq support in EF wasn't so great (couln't create my own filter extension methods).
Is the new EF in .Net 4.0 better. Given what I have stated so far is there a chance I will like it.
The reson I ask this is because I use linq2sql a lot and do not like the feeling that the platform I am using is about to go obsolete. I would like to upgrade to something that is as similar as possible to what I already have.
Thanks for your opinions
It's only an opinion, but I believe that the new EF will be much improved. They will almost certainly have some kind of migration path from Linq to SQL. Whether it will look like Linq to SQL is another story. The two tools have somewhat different philosophies.
While EF will be designed for enterprise scenarios, it is my hope that the next version will still be lightweight enough to serve as an adequate replacement for L2S in small application scenarios.
I am really optimistic about EF 4.0 from all that I have seen thus far. The beta release is already available to MSDN subscribers and it addresses a lot of the concerns around POCO, Persistence Ignorance, N-Tier support and all that. I continue to recommend reading the ADO.NET team blog as a great resource for what's changed.
You can't compare it to the first release because this is a very big overhaul and a lot has changed.
That said, initial adopters always get the worst of it because they are the first to run into bugs and new problems while the late comes can benefit from the lessons learnt by the early adopters.
There has been a lot of improvements. I have ran in to a couple of strange issues but nothing unsolvable yet. It took me a few hours to understand how POCO works meaning they spent a lot of. I recommend you download VS2010 and play around with it yourself!
Have a look at this presentation, and you will know why EF worth your time.
How to Think Like the Entity Framework Presentation: http://blogs.teamb.com/craigstuntz/2009/09/11/38394/
I was listening to a podcast recently that was discussing at length the short comings of Entity Framework (EF).
But, their opinions may need to be taken with a grain of salt (by me), as from what I could gather:
These were folks that were ORM experts.
They either made their living off of ORM tools, or their hobby
They were using ORM tools for large scale applications
They were also very concerned with the uber-tactics of ALT.NET that I'm not necessarily concerned with (YET)
My overall question is:
For what type of project is Entity Framework currently suited?
But here are a few sub-questions that may help you get where I'm headed with that question:
Is EF better than nothing? I'm tired of doing everything by hand.
Does it come close to "solving the same problem" as LINQ to SQL? 2a. If yes, when would one be suited over the other? * found a thread on this question as I was going over questions with this tag, so nevermind *
Does it lend itself to simple 'quick and dirty' applications, such as when the bulk of your administrative CRUD forms?
edit: for those that might be curious, I am mostly working on small to medium sized applications. That can guide your response, or not.
The Entity Framework is suitable for all applications which would benefit from having an ORM layer. Daniel Simmons post goes into detail on this.
http://blogs.msdn.com/dsimmons/archive/2008/05/17/why-use-the-entity-framework.aspx
Entity Framework is similar in many ways to Linq for SQL but is not tied to MS SQL Server which Linq for SQL is. In addition EF supports more flexible mapping between your business/domain objects and the data tables. Linq for SQL supports more of a one to one mapping whereas EF supports ability to map a single object to multiple tables, or a single table to multiple objects. You do have decent designer support in both.
In the open source world, NHibernate is probably the most advanced and in many ways is the more mature product (it certainly supports a wider array of features to some regard). But with EF you get the full support of MS and the close integration into the visual studio toolset and .net framework stack. EF also as a better Linq profider than NH at the time of writing.
For a quick and dirty application i would lean towards Linq for SQL to be honest, if you can live with MS SQL Server and the mapping restrictions.
For a more complex application i would use EF or NHibernate.
You might be interested in a vote of confidence post i gave on the EF
http://blog.keithpatton.com/2008/06/24/A+Vote+Of+Confidence+For+The+Entity+Framework.aspx