I would like to know whether there is a difference in functionality between ODP.net for .net 1.1 and ODP.net for .net 2.0 or higher. Are there any performance differencies?
It depends... 8-)
The provider for .Net 2.0 support more advanced features that allow data insertion and retrieval operation to be much faster but you need to change your code to use them.
If you're willing to change your code and need the new features improvement could be very effective (for example the array parameter functionality could really speed up massive insert operation, I do not remember if it's available in the 1.1 provider but I do not think so).
As for simply using the same code in Microsoft.NET 1.1 with ODP.Net 1.1 or using with Microsoft.NET 2.0 and ODP.Net 2.0 I do not think you will see great improvements.
Related
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.
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.
I have one project using NHibernate 1.2. I know it's old, but I've used it since I'm working off NHibernate in Action, which targets that same version.
I've been thinking I should update my understanding of the tool, as well as the tool itself. But I wonder what the differences are between versions. I know 2.1 has been current for some time, and that 3.0 is in the works.
What benefits or features are gained, lost, or changed when moving to NHibernate 2.1 or 3.0?
Off the top of my head and mixing 2.X and 3.0 features... LINQ support, EventListeners (more powerful Interceptors), System.Transaction support, generics support, multiquery, future queries, SchemaUpdate (rather than just SchemaExport), much better HQL parser, ... Plus numerous bug fixes. A lot has been going on in the NHibernate world since NH 1.2...
With the 3.0.0 release, NHibernate
includes support for LINQ, along with
additional features such as:
Along with a long list of bug fixes
and improvements, it has several new
features including
A new strongly
typed criteria API called QueryOver
Lazy loading of columns
Alias delimiting in generated SQL
Support for DetachedCriteria within
IStatelessSession.
Improved support for LINQ, overcoming the HQL limitations of the previous provider.
Breaking change:
Upgrading users should be aware that
one of the fixes means that null
values in dictionaries are no longer
silently ignored, which has the
potential to break existing
application code.
James Kovacs summarized it pretty well, but for a complete list of changes check https://nhibernate.svn.sourceforge.net/svnroot/nhibernate/trunk/nhibernate/releasenotes.txt
It contains every single bug/improvement/new feature for all NH releases.
You get Linq support!
I started on 2.x+ so I can't say much...but I'll for sure upgrade to 3.0 once it's out of beta. Mainly because QueryOver looks like ICriteria on type safe steriods!
v3: Removal of the dependency on log4Net (which is often a love-it or hate-it thing)
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.
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.