I'm starting some new projects and I want to use PetaPoco (I've used it before in other projects) or NPoco.
I know NPoco is a branch of PetaPoco (based on v4.x), and PetaPoco is now in v5.x.
But it seems that althought NPoco is PetaPoco + some new features, the code bases are now a little bit divergent and changes to PetaPoco cannot easily be integrated in NPoco and viceversa.
Is PetaPoco still in development or is it deprecated/in maintenance mode?
Will all future development done in NPoco?
Not to confuse matters even more, but there's also AsyncPoco, a fork of PetaPoco v5 that adds asynchrony for those on .NET 4.5 or higher. I can't speak to the development status of PetaPoco, but if there are bugs that have gone unfixed or feature requests unanswered, feel free to create issues/pull requests on AsyncPoco. I don't have any sort of roadmap for 1.1 at this point but am open to suggestions and eager to move the project forward if there is interest.
PetaPoco is more like "Finished" than deprecated. It's fine for me that way. No need to add bloat to an efficient product.
That said, if you need a more active product, you should surely go for the NPoco road.
Related
We want to upgrade a rather large and old project from Nhiberate v2.0 to v4.1 to increase the performance further. Does anybody have any useful tips, howto's or best practices? Another option would be to switch to the Entity Framework if that is easier. Any guesses how many days the upgrade would take?
As for the upgrade itself, it should work out of the box, and, yes, you should upgrade it because there are lots of improvements and new features.
As for switching to Entity Framework, lots of things are so different. I suspect that you were not using LINQ with NHibernate 2.0; in Entity Framework, you need to use LINQ. Plus, the mappings are done in a totally different way, using attributes and code in Entity Framework.
I am creating a new project that will run in Azure Web App on the new ASP.NET 5. We are not planning to run it on linux or anything like that, at least now. So the question is, should I try to keep both frameworks if possible just in case or I should prefer one of them. There are e.g. much less dependencies that I can use with dnxcore50 which is not so nice. So the main question is: are there any benefits of using dnxcore50 if running in Azure Web App, like: performance, stability, etc. over dnx451.
I have to start that I'm still the beginner in ASP.NET 5 (like the most other), so I didn't posted my answer before and you should ignore my reputation, because it's come from another subjects, which I know better.
I think that everybody, who switch to ASP.NET 5, ask the same question whether it does make sense to keep both framework in his projects. I try to post below my personal thoughts about the subject.
My personal choice is my short recommendation to you: keep both framework till you find some really important reason to drop one from there.
ASP.NET 5 is still not final. The strategy is not full fixed and it can be changed in a short time later. Just some examples. Previous beta versions have supported "Helios" as an option for hosting ASP.NET 5 applications on IIS. The option was dropped later (see the statement). Even the name dnxcore50 is renamed now to dotnet5.4 at least in all internal Microsoft components (see the announcement). One can suppose that some other things could be changed in the future. Thus I think that putting all your eggs in one basket would be too dangerous now: keeping of both frameworks could reduce the risk.
The next thing, which I found, was the following. dnxcore50 (dotnet5.4 or CoreFX or .NET Core foundational libraries) don't support many features supported by .Net Framework. One important example for me was missing XSD Schema validation (see here and here). I use XML only in combination with XSD Schema validation. I prefer JSON in the most other cases. Kipping of both frameworks in your project could helps you to locate the parts of your code, which could be not yet implemented in CoreFX. It could helps you to move the code in separate component or to change the implementation.
About the performance. One should distinguish potentiality of both frameworks from the current implementation. In general CoreFX was redesigned and decomposed. Many parts of one mscorlib was separated or removed (remoting, AppDomains and so on). It means that the performance of CoreFX should be better. Theoretically the factored API can provide better performance. Moreover one can more easy improve one parts of CoreFX and publish new version with improved performance. More modules instead of having one monolith gives us the new way for improvement of the performance and for fixing the bugs. On the other side replacing of dependencies to new version could be origin of new compatibility problems and thus it increases the risk and could decrease the stability. By keeping of both frameworks we can test whether the new problem exist in alternative framework. It allows us to suppose that the last changes of dependencies and not the last changes of our main code is the origin of new problems.
I can continue with pros and cons of the usage of every framework, but nodoby like to read long text and all my arguments forward me to the same practical decision: keeping by default of both frameworks in my projects as soon as I would find out a real requirement to drop one from the frameworks.
No major advantages really so far.
This might change in the future and why I'm planning to target both (CoreCLR and .NET 4.6). A lot of investment is being spent in CoreCLR but also on Docker and Service Fabric.
Just my 2 cents.
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)
Let's assume you're in the middle of a long running project (long running = several years) and, as expected, there will be several things coming up with brand new releases. There might be a new .Net Framework with brand new features (e.g. Linq, Entity Framework, WPF, WF...), a new Visual Studio or V.next of your favorite Control Library, a new Mock Framework and a lot more things.
What are your guidelines for handling these technology updates? Do you adopt them instantly or do you ignore them until the end of the project? Do you have different guidelines for different things (Tools, Frameworks, supporting stuff)?
In my experience, these decisions are always made on a case-by-case basis. Several factors are considered, including:
How mature is the new technology? Does the organization like to be at the forefront working with bleeding edge new technologies, or does it prefer to work with proven tools and methodologies?
What skill sets do your people have? Are they consistent with use of the new technology, or is more training needed? Will improved productivity outweigh the time it takes to come up to speed?
What investment do you have in the existing technology? What is the cost of moving to the new technology? How much rework and rewriting of code is involved?
What is the requirement? Is it supported by the existing techology, or are new tools needed to fulfill the requirement?
What are the performance expectations? Does the new technology provide a performance improvement that cannot be met with the old technology?
What about the technological culture? Is the organization vendor specific (e.g. a Microsoft shop)? Can open-source code be used?
What is the scope of the project? Is it a large project that would benefit from supporting technologies like frameworks and tools, or is it a small project that would be unduly weighed down and complicated by these things?
How is the new technology supported? Does the vendor have good documentation? Is there someone you can talk to if you have problems? Or are you an organization that has people that know how to solve problems without a support contract?
Is the technology comfortable to work with? Does it seem to make sense? Is it clean and elegant? Do other people seem to like it? Are other people having problems with it?
Is the technology the latest flavor of the week? Has it proven itself in the battlefield to produce tangible results, or is it just a religion?
How much time do you have to learn the new technology and iron out the kinks? Do the benefits outweigh the costs?
As a very brief example, I chose Link to SQL for my most recent project, because the project was complex enough to warrant an ORM, L2S performs well and is lightweight, we are a Microsoft Shop, and it is my sense that the Entity framework is not quite ready for prime time (even though Microsoft says that it will be the go-to framework for the future).
Stick with what you've started with.
A large and long running project often comes with a huge and highly complex code-base. Any change or upgrade to a new version of a library can add bugs in very subtle and unexpected ways.
Also: For large projects the tools and libraries used should have been tested and evaluated in the design-phase. Unless you find a show-stopper or a security issue it's best to not upgrade.
Always remember: Don't change horses in the middle of a stream. :-)
I would say different factors pitch in, like-
Say a software is nearing its end of life, for example last April, Microsoft retired mainstream support for SQL Server 2000, and your product uses it then its wiser to go for the next version of SQL Server in your next release.
Another factor which comes into play is how much value does the new features in the latest release of a software would bring to your product. It may well be the case that the new release of .NET framework has something which does not add any value to your product, then that does not build a strong case to upgrade.
Budget is also an important factor. I think you need to upgrade licenses in order to step up to the next release unless you are already part of something like software assurance.
Training to the team is also a factor. If the latest release is going to add to your product then you will have to train your team as well.
Well, there could be other telling factors too. These were the ones off the top of my head. I hope it helps.
cheers
If you're talking about a framework-specific example, the biggest piece of advice I'll give you is keep the system and your application separate. This is why I love patterns such as Model-View-Controller - it keeps your code modular and means you can upgrade sections without breaking the app as an entirety.
On a more practical level, if your framework has a Git or SVN repository, checkout the usual 'system' directory from the repo, then you can call 'svn update' occasionally to keep up with the latest and greatest builds.
I would suggest that the project not last that long. Develop the application in smaller pieces with iterations every couple months. That way, as new technology comes out, you can make the necessary change and implement updates as you go rather then have to decide to redevelop the whole application. As you say, trying to develop the whole application as things change just doesn't work.
As another poster said, it's certainly a case-by-case basis thing. What you can upgrade and when is determined mostly by how hard or easy it is to test the new version of the system. Having a comprehensive automated test suite for your application helps a lot with this.
Generally, I try to update to the latest stable release of libraries and so on as often as possible, because that makes maintenance easier. If you don't update, you may find yourself patching or working around bugs in the version of the library you are using. If you update less frequently, each update will be more work because you have more changes to deal with, and it's been longer since you last touched the system, and thus you remember less about it.
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.