entity framework 6 vs core - vb.net

I'm still struggling to decide whether to use EF6 or core for my small business management system I'm going to create in VB net. I've already created an SQL database that has about 100 tables and the data won't be very intensive. I've read that core doesn't support model first but I've also read that it's possible to do code first that's based on an existing database. (didn't really understand that but I'll research it if I decide to go core).
A few months ago I was determined that I'd just stick to v6 which has been around forever, most popular, and probably has all the functionality I'd ever need for my small business and won't be going anywhere in the near future.
But now I see core.2 came out and I understand that since core was build from the ground up, MS has a special interest in developing it to be the best EF out there. I have a feeling that although v6 won't be going anywhere soon, that MS will be putting most of there effort into core with each new version and of course, you can always upgrade to newer versions but as I understood, will never be able to convert a project from v6 to core. So I feel like I'd regret starting with v6 and being stuck with it and missing out on the "core-train".
What do you think?

The EntityFrameworkCore is not mature now, we have met lots of issues. So you should wait for 3.0 if you want to use it in your projects.

I have a feeling that although v6 won't be going anywhere soon
I believe you are right here. Microsoft may add some fixes on EF6 but they will probably not do any heavy development here since they will put their effort on EF Core.
Disclaimer: I'm the owner of the project Entity Framework Classic
Entity Framework Classic is a supported version from the latest EF6 code base. It supports .NET Framework and .NET Core and overcomes some EF limitations by adding tons of must-haves built-in features.
There is a Community Version (Free) and Enterprise Version (Paid).
As being the owner of several EF library such as Entity Framework Extensions, Entity Framework Plus, EF Dynamic Filter, EF Effort, EF Graph Diff, and more. You can expect this library to have some ongoing development.

Related

latest version of Entity framework vs NHibernate

considering the latest version of Entity framework as against NHibernate, is there a reason why I should use NHibernate as opposed to the latest version of Entity framework?
Are there features of Nhibernate that is not covered by current version of Entity framework?
thanks
There are tons of posts about differences between NH and EF - do some yourselves research if you want to get complete answer.
Short version:
EF 4.1 brings only new way to use EF 4.0 - it means new simplified API called (DbContext) and code mapping. Both these new features are more limited than original EF 4.0.
EF 4.3 brings code-first migrations for incremental data model development.
EF 4.5 Beta / EF 5.0 Beta brings support for enums, spatial types, table valued functions, auto compiled queries + performance and API improvements.
There are a lot of NH's features which are still not possible in EF
More possibilities for complex mapping
Custom type mapping
Batch command execution
Future queries
2nd level cache
Extensibility and a lot of ready to use extensions
A lot of hooks where you can replace NH's default implementation with your own or add new logic
etc.
EF has better LINQ support and it is from MS - for many companies this is important decision point. You can check data user voice to see what features are currently requested from ADO.NET team for next releases.

Entity Framework vs. nHibernate for Performance, Learning Curve overall features

I know this has been asked several times and I have read all the posts as well but they all are very old. And considering there have been advancements in versions and releases, I am hoping there might be fresh views.
We are building a new application on ASP.NET MVC and need to finalize on an ORM tool. We have never used ORM before and have pretty much boiled down to two - nHibernate & Entity Framework.
I really need some advice from someone who has used both these tools and can recommend based on experience. There are three points that I am focusing on to finalize -
Performance
Learning Curve
Overall Capability
Your advice will be highly appreciated.
Best Regards,
I would use Nhibernate. I would pickup Sharp Architecture as a great framework that wraps NHibernate, ASP.NET MVC and a bunch of other open-source tools into a coherent whole that will give you a solid architectural foundation.
Nhibernate is more mature than EF4. It is well supported by the community. As long as you are willing to get your hands dirty from time to time, you will like it. It's support for LINQ is currently a little weak but it is rapidly getting better. The learning curve is not bad, but things like session management can be a little confusing at first. One of the reasons I like Sharp Architecture is they have all the NHibernate stuff you will need in place and plenty of guidance on how to use it properly in an ASP.NET MVC project.
EF4 has the MS stamp of approval. It is pretty good now but still behind NHibernate. It is a perfectly good choice and you will find lots of docs from MS, MS support and eventually more developers that are familiar with the ins and outs. I should also mention that the Sharp Architecture folks are adding support for EF4 to their overall framework. They will still support NHibernate, but you will be able to use EF4 if you like.
I think it takes more time to learn NHibernate.
EF provides graphical designer, unfortunately NHibernate doesn't have a generic designer. BTW it's not a problem. If you design in domain-driven (DDD) manner, you will design your entities first and you don't care about database structure (as you used to), NHibernate will handle that for you.
EF 4 got closer to NHibernate. I wouldn't start working with EF 3.5, it lacks a lot of features.
If you think NHibernate is too complicated at first sight, you can start with frameworks built on top of NHibernate. ActiveRecords and Sharp Architect are good examples.
AFAIR EF 3.5 supported only SQL Server 2000. It couldn't handle the new data types from SQL Server 2005. I have no information on EF 4 but I suppose it support these improvements.
If you use NHibernate in real word applications, you have to build an infrastructure. E.g. I implemented the Unit of Work and Repository patterns to be able to write tests and create layers in my application. You have to expect the same using EF. Detaching and attaching entities in EF 3.5 was not an easy thing, I had to write tricky extension methods to mark fields dirty and so on. I hope they solved it in EF 4. There is no such problem with NHibernate.
You don't have to write HQL queries in NHibernate, you can use the LINQ provider. I think it's very important. :)
All in all NHibernate is a mature product with good community and commercial support. EF is young but strongly supported by Microsoft. Oh, and EF is a Microsoft-only thing while you can port your NHibernate knowledge to Java as well. It this counts for you.
I'm trying to look into this...
After building apps into both, NHibernate is definitely more powerful, but it's also quite clunky where EF is very clean. And after working with Rails/ActiveRecord, both are very feature rich in comparison, so either would definitely work!
I noticed that NHibernate keeps track of what it just ran, and if it just ran a statement, it doesn't exectute it again, so a properly designed app will run minimal database statements. I know that EF is not exactly slow either, but I'm not sure if it caches statements and results in the same way. For a large app, this could save some database resources!
So in short, NHibernate for functionality and configurability, and EF 4.0 for cleanliness and a quick easy learning curve. Also, one should expect EF in the next version or two should may catch up to or surpass NHibernate in functionality too, so it may make sense to have some familiarity with both.
just take a look at this
http://gregdoesit.com/2009/08/nhibernate-vs-entity-framework-a-performance-test/

How Do The Entity Framework 2 And NHibernate Compare?

I would basically like to know things such as:
Advantages/disadvantages between the two?
Similarities/differences between the two frameworks?
How are they similar/different architecturally?
How much boilerplate code is needed to use each?
Can the Entity Framework be used efficiently outside of Visual Studio compared to NHibernate? Is the Entity Framework more efficient than NHibernate when used with Visual Studio?
Note: This question refers to the Entity Framework 2 (currently still in development).
Disclaimer: This post is based on my current knowledge of what the next version of Entity Framework will be like. That might be inaccurate or it might change until the next version is actually relased.
General Approach:
The main approach of Entity Framework (EF) is using their graphical designer tool to create an Entity Data Model and to generate domain classes as well as mapping from that model. There is support for other approaches as well, but that way of working will probably always be the main one.
NHibernate (NH) is a text based tool which requires the user to write all the domain classes and mapping manually, if you don't turn to third party software for code generation, such as MyGeneration of CodeSmith, or additional convention over configuration support, such as Fluent NHibernate.
Code Generation:
Code generation is a major part of standard EF usage, either by using their graphical designer tool or by using their command line tools. The availability of both GUI and command line tools is a plus since makes EF easy to get started with as well as allowing for more advanced usage that can be automated, for example in a build process.
Code generation is not supported by NHibernate, except for the schema generation stuff if you want to count that as code gen. You can get code generation if you turn to third party software though.
Database Schema Generation:
EF will add support for model first development, by allowing the user to generate a schema from an Entity Data Model. NHibernate has had schema generation support for a long time. The difference here is how you create your "model", as mentioned earlier.
LINQ:
EF will have improved their whacky LINQ implementation from v1 and NH have now reached version 1.0 of LINQ to NH, so there should not be any major differences between the two in that regard.
POCO:
EF will add better support for the Domain Driven Design approach and the use of domain classes that are separated from the data access layer. However, since POCO is not the main use case of EF I can't really see how their POCO support could ever reach the level of NHibernate. The POCO support in EF is still young, and to me it feels more like that it is a bonus if you are a POCO/DDD supporter and you find yourself working on EF for some reason.
The entire NHibernate framework is build for POCO development, by DDD people, and they have reached version 2.1 as well as taking advantage of all the work put into Hibernate on the Java side. NHibernate will probably remain the no 1 choice for the DDD/POCO/ALT.NET crowd for quite some time.
Lazy Loading:
The next version of EF will include support for automatic lazy loading. Automatic lazy loading has been an important part of NHibernate for a long time.
Learning Curve:
Both frameworks are complex and powerful, and hence take a long time to master. But EF is quite beginner friendly since it is integrated into Visual Studio, with its graphical designer tool, and since it can generate a lot of stuff for you without you having to know just about anything about the framework. However, if you want to dig deeper into EF and really learn the framework, you should be prepared to spend quite a lot of time using it.
NHibernate has a notorious learning curve, but some recent improvements have reduced it a bit. Now that LINQ to NH is at v1.0 the query syntax will be easier to understand for developers new to NH, and the Fluent NHibernate project is improving the mapping experience, and even working on automatic mapping, which is getting better and better all the time.

Compelling Reasons to Migrate from ASP.NET 2.0 to ASP.NET 3.5

Forgive me if this is a repeat question. I've searched StackOverflow and did not find the answer to my question, so here goes.
We currently have a web application running ASP.NET 2.0 with AJAX Extensions 1.0 and SQL Server 2005 running, is deployed on IIS 6 and developing in VS2005. All works great, but I'm trying to find compelling reasons to migrate. The clients we serve to do not permit plugins in general in browsers, so Silverlight is not a reason for us to migrate. Also, we don't have any plans to migrate to SQL Server 2008 any time soon and ASP.NET MVC is not in the works either.
Here's my reasons to migrate. I would like people to comment on them or add to the list:
I want to work with the newer .NET stuff (and I think other developers would too. Also appealing to prospective employees)
Want to keep the technology up to date.
Extension methods
PageMethods in WebControls
WCF
LINQ maybe (we currently use AutoSproc for our DAL)
ASP.NET AJAX built-in to ASP.NET 3.5 (not really a big deal though)
VS.NET 2008 JavaScript Intellisense
My favorite parts are:
Lambda expressions
Functions available in the
System.Data.Linq namespace:
Where(...), OrderBy(...),
ForEach(...)
Extension methods (add a "ToDelimitedString(...)" to all IEnumerable!)
Visual Studio 2008 is nicer with
HTML/web syntax and debugging,
including the aforementioned
Javascript intellisense and
debugging.
Each of these allow you to write code in a more productive manner.
It largely eliminates the boilerplate "foreach", "if x != null", and other boring constructs.
The javascript intellisense is a huge improvement over anything that's come before. But at the same time it still fails in some very spectacular ways. All in all a good step but not something I've been able to use as much as I'd like.
The extension methods and linq (linq to objects and lambdas, not just linq to sql) are very cool, but since you have an orm already set up you won't use them as much as you'd like either.
WCF is okay, but you're probably not going to re-write your existing services for it.
I think the biggest reason up there is keeping your employees happy and attracting good new ones.
You have absolutely no reason to upgrade, from a business prospective.
You have absolutely every reason to upgrade, from a developer prospective.
Just keep in mind that SQL 2008 is not backwards compatible with SQL 2005, meaning, if you develop something in SQL 2008, chances are, your 2005 platform will barf at it. I just recently experienced this with SSIS packages.
LINQ is a reason to upgrade, even if you don't swap out your DAL, or don't do it for a while. In the product I've been working on lately, our development schedule is such that there's no room to change our DAL to a LINQ-based one for a while yet, but even so I find good reasons to use LINQ-to-Objects and/or LINQ-to-XML in probably 60% of the classes I touch, and I love it.
Everything still runs on .NET 2.0, it's just library and language enhancements and an improved IDE experience, which are made to increase productivity. Increased productivity = justification.
I use LINQ all the time now, every single day. It's not just for your DAL. It's about querying anything, with the same API over top. More generally, lamba expressions provide you with the ability to do some things that are very complicated and take a lot more code without them. Anonymous types are very useful as well.
All the points mentioned are valid.
But as a developer, when facing this kind of question, I always ask myself from the other side.
What is Compelling Reasons NOT to Migrate from ASP.NET 2.0 to ASP.NET 3.5? I find it easier to get myself motivated to upgrade.
The free Microsoft ASP.net Chart control and the new version of Ajax tool kit both require 3.5. If i'm not mistaken.

Moving from vb.NET (2003) to vb2005 What are some of the benefits?

We are changing from vs2003 to vs2005 and use vb as our primary language, I am looking for some of the changes to VB that will be helpful in our ASP.NET development. Can someone point me to a list (maybe from microsoft?) or provide some of their favaorite differences between the two versions?
WHOA! Not so fast there, buddy! What's the rush? Relax, guy. Give it a few more years.
Any .NET developer not working version 3.5 of the framework is just wasting time. Every single bit of it... Linq, WPF, lambdas, WCF, GENERICS, I could go on... Every SINGLE bit of it is gold. I'd rather play on a highway than target 1.1. Its like night and day.
Do yourself and your team a favor... Skip 2k5 and hit 2k8.
What's new in VB 2005 (from MS)
The same topic covered in Code Magazine
From a language perspective, the addition of Generics and Nullable types (second link) (built on Generics) was a pretty compelling story for my work. The My namespace provides VB developers with quite a few shortcuts into "somewhat" more complicated features of the system.
From an ASP.NET perspective, even though they weren't VB-specific, the addition of the Master Page framework and MembershipProvider architecture were also very valuable.
Here's a fairly comprehensive list from Microsoft of all the Visual Studio 2005, language and major .NET framework changes.
For what it's worth, you might consider just jumping over 2005 and right into 2008, with .NET 3.5.
Rick Strahl takes stock of the major changes and provides a personal perspective on some of the highs and lows.
.NET 1.1 to .NET 2.0 Migration
Article 1
Article 2
Better IDE for one.
I found the biggest improvements from .Net 1.1 to 2.0 were generics and yield return for easy implementation of ienumerables.
I personally find some of the IDE changes to be of the best benefit.
The fact that the designer DOESN'T re-format your code as it feels like it
The fact that standard layout is DEFAULT rather than grid layout
Improvements in intellesence
In addition to the IDE changes, if I had to pick 1 .NET 2.0 thing that is a huge helper I would say generics.