I have been sold on the fun of using linq in areas other than pure database interaction. (See Calling fellow code nerds - Alternatives to Nested Loops?).
We are stuck on 2.0. I have told the powers that be about the ease of updating to 3.5 (we have already migrated to VS2008) but they are wanting a list of "benefits" for upgrading.
Can those that have experience in 3.5 help provide some talking points for the benefits of updating an existing app to 3.5?
UPDATE: Found an additional reason: Microsoft's inclusion of Charting tools for Asp.Net as a patch on top of 3.5! They get their business value, I get the fun...
Can YOU make a case for it? Sounds like you want it because LINQ is fun. Other people are mentioning features that are fun. I've always had a problem selling fun features to management because they aren't very compelling reasons to potentially disrupt an environment.
Honestly, it really depends on what you are using C# for. Are you a web developer, system admin, something else? Taking a general approach, I would use the following selling points (you will need to do some work to prove these things):
Zero-disruption for end-users when upgrading. Upgrading to the new version will be seamless and we will have a thoroughly reviewed test plan for updating all clients to this version. All of our old applications that require .NET 1.x or .NET 2.0 will still work perfectly.
Programmer Efficiency. You could mention how more of the Windows API is wrapped by .NET classes, thus making programmer more efficient because they don't have to P/Invoke as much. LINQ makes your more productive because of x, y, and z. Lambda expressions make you more productive because of x, y, and z.
Ease pains of future OS migration. Moving to WPF now will prepare us for Vista/Windows 7. We won't have to migrate applications using the now deprecated "Windows Forms" to WPF, because we will already be using it.
More applications purchased from 3rd parties will require it, so we will have to upgrade sooner or later.
In the end, you need to prove that at the very least, this move will not cost you money in terms of increased support or testing costs. If you can show it will make you be more productive and it will be a rather painless switch, then you will get your wish.
Maybe you should talk to some Java developers who are probably still forced to develop using 1.3 or 1.4 despite 1.5 being out for over 3 years and 1.6 for a couple... it appears platform consistency across the business is often of greater importance than the benefits of using the latest and greatest.
Also remember that 3.5 is just additional BCL libraries. You are still running on CLR 2.0. Same is true for 3.0. Usually when people find out that the underlying framework is the same and that you are just adding in new libraries they are more likely to go along with it.
You don't need .NET 3.5 to get LINQ or C# 3.0 features. You can implement your own LINQ for .NET 2.0. I am using C# 3.0 all over the place in my .NET 2.0 application. I don't know the full details on how to start the conversion process because I didn't set it up myself. This might be a good link for you: http://www.danielmoth.com/Blog/2007/05/using-c-30-from-net-20.html.
http://msdn.microsoft.com/en-us/library/ms171868.aspx
Transitioning onto 3.5 would help you reap the benefits/ features of:
LINQ to (Entities/ XML / Objects / Datasets etc ).
WCF, WF and WPF.
ASP.net MVC where MVC is kind of a de facto standard in other
platforms like Ruby/Python which
allow you pure HTML/ Javacript based
development.
ORM options with ADO.net Entity
Framework/ Linq to Sql
4.
With a few addons you can have
support for dynamic languages
like
IronPython/IronRuby.
Oh ya I almost forgot ADO.net Data Services..one of my fav.
These are the few benefits that immediately come to my mind.
In my experience, the addition of LINQ and Extension methods alone have made many previously arduous and/or time consuming tasks much easier and faster. The increased developer productivity from that alone is worth the upgrade effort IMHO.
Lambda expressions are awesome. There is no end to the places where I find that lambda expressions help me out in a very concise and readable way.
Automatic properties, while being a simple concept, really help making the code base smaller and clearer.
Also, I sencond the extension methods.
Before I even opened this question I had my answer: LINQ - it's one of the greatest extensions ever in .NET - I love it. It took me a few days to figure out, but now I've got it, I use it all over the place. The ability to query collections and arrays is worth the upgrade alone in my mind.
Decreased development time (and therefore increased ROI)
Less time wasted finding workarounds for .NET bugs that've been fixed in newer releases.
Extension methods for native types (in a similar fashion to JavaScript prototyping)
LINQ extensions - they take a couple of days to get your head around, but it's awesome!
LINQ to XML makes working with XML so much simpler
LINQ to objects/collections
A nice new 3.5 poster from Microsoft that you can pin up in your cubicle.
As a manager if I have a happier more productive team that is producing more in less time, then its a no brainer.
Ask yourself this: Will the developers be more effective and will their increased productivity actually increase benefit to the company or reduce corporate costs once you've considered the upgrade/transition/installation on the servers/additional testing etc? If the answer is truly yes, then do the upgrade and quit arguing about it.
Related
Because of specifics of my current project, I have to keep using .NET 2.0. Are there any Entity Framework-like ORMs for .NET 2.0?
I'm absolutely OK with non-LINQ interface. Syntax like users.Where(u => u.Age > 100).Count() is fine.
I need to use DB-first approach: I already have a DB with about 30 tables and just considering the ways of simplifying work with it. So, I'd really appreciate if it's possible to generate the required code from existing DB.
It's also OK if it won't generate all the required code but provide the way to describe DB structure manually (using attributes, for instance). Basically, I just want to be able to build more or less sophisticated queries without messing with real SQL, SqlParameters and DataSets/DataTables with all these int.Parse(row[12].ToString()) (that's a legacy code I'm trying to get rid of)
Also, that would be great if I'm be able to "override" some particular "queries" with calls to existing stored procedures.
The most important is p.2 - DB first. Is there anything of this kind? Or am I absolutely wrong with my thoughts? Will appreciate any ideas.
Your best option is to check out NHibernate. Many (most?) people consider consider it more feature complete and powerful than EF 4.1, plus there are plenty of resources here on stackoverflow and the rest of the web to guide your development process.
Be sure to look into Fluent NHibernate to make mapping from your database to C# objects easy. The alternative of editing XML files is complex, clunky, and time consuming.
Note that you might need to use an older, but still completely functional, version of NHibernate that is compatible with .NET 2.0 (I think, but am not positive, that the more recent versions require .NET 3.5).
There is plenty of available ORMs but some of them are commercial (LLBLGen Pro). The good choice for you is probably NHibernate 2.1 (I think NHibernate 3.x requires .NET 3.5).
You should also thing about moving forward to a newer .NET version. Starting a new development on .NET 2.0 should be avoided and involving a new technology to existing old code base IMO spoils application's architecture and maintainability.
Edit:
So, I'd really appreciate if it's possible to generate the required code from existing DB.
The most important is p.2 - DB first.
ORM and code generation are two different areas. DB first doesn't mean code generation - it means mapping to existing database without needs to change the database. It is not point of ORM to generate code for you. The point of ORM is to allow you to map DB to classes and abstract querying. If the most important point for you is code generation you should look for something else then ORM. NHibernate doesn't have such code generation included but there are some additional projects which add similar features.
I'm planning on starting a new project, and am evaluating various web frameworks. There is one that I'm seriously considering, but I worry about its lasting power.
When choosing a web framework, what should I look for when deciding what to go with?
Here's what I have noticed with the framework I'm looking at:
Small community. There are only a few messages on the users list each day
No news on the "news" page since the previous release, over 6 months ago
No svn commits in the last 30 days
Good documentation, but wiki not updated since previous release
Most recent release still not in a maven repository
It is not the officially sanctioned Java EE framework, but I've seen several people mention it as a good solution in answers to various questions on Stack Overflow.
I'm not going to say which framework I'm looking at, because I don't want this to get into a framework war. I want to know what other aspects of the project I should look at in my evaluation of risk. This should apply to other areas besides just Java EE web, like ORM, etc.
I'll say that so-called "dead" projects are not that great a danger as long as the project itself is solid and you like it. The thing is that if the library or framework already does everything you can think you want, then it's not such a big deal. If you get a stable project up and running then you should be done thinking about the framework (done!) and focus only on your webapp. You shouldn't be required to update the framework itself with the latest release every month.
Personally, I think the most important point is that you find one that is intuitive to your project. What makes the most sense? MVC? Should each element in the URL be a separate object? How would interactivity (AJAX) work? It makes no sense to pick something just because it's an "industry standard" or because it's used by a lot of big-name sites. Maybe they chose it for needs entirely different from yours. Read the tutorials for each framework and be critical. If it doesn't gel with your way of thinking, or you have seen it done more elegantly, then move on. What you are considering here is the design and good design is tantamount for staying flexible and scalable. There's hundreds of web frameworks out there, old and new, in every language. You're bound to find half a dozen that works just the way you want to think in your project.
Points I consider mandatory:
Extensible through plug-ins: check if there's already plug-ins for various middleware tasks such as memcache, gzip, OpenID, AJAX goodness, etc.
Simplicity and modularity: the more complex, the steeper the learning curve and the less you can trust its stability; the more "locked" to specific technologies, the higher the chances that you'll end up with a chain around your ankle.
Database agnostic: can you use sqlite3 for development and then switch to your production DB by changing a single line of code or configuration?
Platform agnostic: can you run it on Apache, lighttpd, etc.? Could you port it to run in a cloud?
Template agnostic: can you switch out the template system? Let's say you hire dedicated designers and they really want to go with something else.
Documentation: I am not that strict if it's open-source, but there would need to be enough official documentation to enable me to fully understand how to write my own plug-ins, for example. Also look to see if there's source code of working sites using the same framework.
License and source code: do you have access to the source code and are you allowed to modify it? Consider if you can use it commercially! (Even if you have no current plans to do that currently.)
All in all: flexibility. If I am satisfied with all four points, I'm pretty much done. Notice how I didn't have anything about "deadness" in there? If the core design is good and there's easily installable plug-ins for doing every web-dev 3.0-beta buzzword thing you want to do, then I don't care if the last SVN commit was in 2006.
Here are the things I look for in a framework before I decide to use it for a production environment project:
Plenty of well laid out and written documentation. Bad documentation just means I'm wasting time trying to find how everything works. This is OK if I am playing around with some cool new micro framework or something else, but not when it's for a client.
A decently sized community so that you can ask questions, etc. A fun and active IRC channel is a big plus.
Constant iteration of the product. Are bugs being closed or opened on a daily/weekly basis? Probably a good sign.
I can go through the code of the framework and understand what's going on. Good framework code means that the projects longterm life has a better chance of success.
I enjoy working with it. If I play with it for a few hours and it's the worst time of my life, I sure as hell won't be using it for a client.
I can go on, but those are some primary ones off the top of my head.
Besides looking at the framework, you also need to consider a lot of things about yourself (and any other team members) when evaluating the risks:
If the framework is a new, immature, "bleeding-edge" framework, are you going to be willing and able to debug it and fix or work around whatever problems you encounter?
If there is a small community, you'll have to do a lot of this debugging and diagnosis yourself. Will you have time to do that and still meet whatever deadlines you may have?
Have you looked at the framework yourself to determine how good it is, or are you willing to rely on what others say about it? Why do you trust their judgment?
Why do you want to use this rather than the "officially sanctioned Java EE framework"? Is it a pragmatic reason, or just a desire to try something new?
If problems with the framework cause you to miss deadlines or deliver a poor product, how will you talk about it with your boss or customer?
All the signs you've cited could be bad news for your framework choice.
Another thing that I look for are books available at Amazon and such. If there's good documentation available, it means that authors believe it has traction and you'll be able to find users that know it.
The only saving grace I can think of is relative maturity. If the framework or open source component is mature, there's a chance that it does the job as written and doesn't require further extension.
There should still be a bug tracker with some evidence of activity, because no software is without bugs (except for mine). But it need not be a gusher of requests in that case.
I like C# 3.0 features especially lambda expressions, auto implemented properties or in suitable cases also implicitly typed local variables (var keyword), but when my boss revealed that I am using them, he asked me not to use any C# 3.0 features in work. I was told that these features are not standard and confusing for most developers and its usefulness is doubtful. I was restricted to use only C# 2.0 features and he is also considering forbidding anonymous methods.
Since we are targeting .NET Framework 3.5, I cannot see any reason for these restrictions. In my opinion, maybe the only disadvantage is that my few co-workers and the boss (also a programmer) would have to learn some basics of C# 3.0 which should not be difficult. What do you think about it? Is my boss right and am I missing something? Are there any good reasons for such a restriction in a development company where C# is a main programming language?
I have had a similar experience (asked not to use Generics, because the may be confusing to my colleagues).
The fact is, that we now use generics and non of my colleagues are having a problem with them. They may not have grasped how to create generic classes, but they sure do understand how to use them.
My opinion on that is that any developer can learn how to use these language features. They may seem advanced at first but as people get used to them the shock of newness lessens.
The main argument for using these features (or any new language features) is that this is a simple and easy way to help my colleagues advance their skills, rather than stagnating.
As for your particular problem - not using lambdas. Lots of the updates to the BCL have overloads that take delegates as parameters - these are in many cases most easily expressed as lambdas, not using them this way is ignoring some of the new and updated uses of the BCL.
In regards to the issues with your peers not being able to learn lambdas - I found that Jon Skeets C# in depth deals with how they evolved from delegates in a manner that was easy to follow and real eye opener. I would recommend you get a copy for your boss and colleagues.
You boss is going to need to understand that language (and other) improvements are designed to give developers more capabilities, and make them more efficient in completing the task at hand, and that if he is not going to allow them for unknown reasons then:
The development team isn't producing at its greatest potential.
The company isn't benefiting from increased efficiency/productivity.
like others have said developers aren't worth their salt if they can't keep up with some of the latest improvements in the language that they are using on a daily basis. I suspect your boss hasn't done much coding lately and it is his inability to understand the latest language improvements that has motivated this decision.
I was told that these features are not standard and confusing for most developers and its usefulness is doubtful. I was restricted to use only C# 2.0 features and he is also considering forbidding anonymous methods.
Presumably roughly translates to your boss meaning...
These features are confusing for me, and I don't find them useful because I don't understand them.
Which is fairly symptomatic of the Blub paradox (well, or just sheer laziness). Either way there's no merit in what he's saying, and you should start looking for another job if he continues down that road.
If the project is strictly C# 3+ from now on, then you would not break the build by including these items. However, before using them you should be aware of the following:
You can't use them if the project lead gets to make the decision and votes no.
Other than that, you should use them where it makes the code significantly easier to maintain.
You should not use them in ways that are confusing, or unnecessary in the sense that they do not significantly improve the maintainability of the code. This does mean you should not use them where the code is effectively the same or barely improved.
If Microsoft didn't define the standard and these were features that they added to a non-Microsoft language, I would say your boss might have a point. However, since Microsoft defines the language and uses these very features in implementing significant parts of .NET 3.5 (and 4.0), I'd say that you'd be foolish to ignore them. You may not choose to use some of them -- var, for instance, may not be acceptable in all environments due to coding standards -- but a blanket policy of avoiding new features seems unreasonable.
The trickier bit is when should you start using new features, because they can be confusing and may delay development. In general, I choose to use new language features and platform elements on new projects. I often avoid using them on projects that are currently in development when the feature/framework enhancement comes out, deferring until the next project. On a long project, I might introduce them at a significant milestone if the amount of rearchitecting is small or the feature is worth the changes. Normally, I'd wait until the project is due for significant changes anyway and then evaluate if refactoring to newer features is warranted.
The jury is still out on the long term consequences of some features, but if their main rationale is 'it is confusing to other developers' or something similar than I would be concerned about the quality of the talent.
I like C# 3.0 features especially
lambda expressions, auto implemented
properties or in suitable cases also
implicitly typed local variables (var
keyword), but when my boss revealed
that I am using them, he asked me not
to use any C# 3.0 features in work. I
was told that these features are not
standard and confusing for most
developers and its usefulness is
doubtful.
He's got a point.
Following that line of thought, let's make a rule against generic collections since List<T> doesn't make any sense (angle brackets? wtf?).
While we're at it, let's eliminate all interfaces (when are you ever gonna need a class without any implementation?).
Hell, let's go ahead eliminate inheritance since its so tricky these days (is-a? has-a? can't we all just be friends?).
And use of recursion is grounds for dismissal (Foo() invokes Foo()? Surely you must be joking!).
Errrm... back to reality.
Its not that C# 3.0 features are confusion to programmers, its that the features are confusing to your boss. He's familiar with one technology and stubbornly refuses to part with it. You're about to enter the Twilight Zone Blub Paradox:
Programmers get very attached to their
favorite languages, and I don't want
to hurt anyone's feelings, so to
explain this point I'm going to use a
hypothetical language called Blub.
Blub falls right in the middle of the
abstractness continuum. It is not the
most powerful language, but it is more
powerful than Cobol or machine
language.
And in fact, our hypothetical Blub
programmer wouldn't use either of
them. Of course he wouldn't program in
machine language. That's what
compilers are for. And as for Cobol,
he doesn't know how anyone can get
anything done with it. It doesn't even
have x (Blub feature of your choice).
As long as our hypothetical Blub
programmer is looking down the power
continuum, he knows he's looking down.
Languages less powerful than Blub are
obviously less powerful, because
they're missing some feature he's used
to. But when our hypothetical Blub
programmer looks in the other
direction, up the power continuum, he
doesn't realize he's looking up. What
he sees are merely weird languages. He
probably considers them about
equivalent in power to Blub, but with
all this other hairy stuff thrown in
as well. Blub is good enough for him,
because he thinks in Blub.
When we switch to the point of view of
a programmer using any of the
languages higher up the power
continuum, however, we find that he in
turn looks down upon Blub. How can you
get anything done in Blub? It doesn't
even have y.
C# 3.0 isn't hard. Sure you can abuse it, but it isn't hard or confusing to any programmer with more than week of C# 3.0 experience. Your boss's skills have just fallen behind and he wants to bring the rest of the team down to his level. DON'T LET HIM!
Continue using anonymous funcs, the var keyword, auto-properties, and what have you to your hearts content. You won't lose your job over it. If he gets pissy about it, laugh it off.
Like it or not, if you plan on using LINQ in any situation, you're going to have to utilize some of the C# 3.0 language specs.
Your boss is going to have to warm up to them if he wants to utilize the feature sets you get from 3.5, which are numerous and worth your time investing in.
Also, from my experience in leading teams, I've found that using the 3.0 specs actually has helped devs readability and understanding of the code base. There's about a weeks worth of time that is spent by the dev trying to understand what the syntax means, but once they get it they much prefer the new way over the old way.
Perhaps you can do a presentation once a week on each feature to everyone and get some of the developers on your side to help convince management of the benefits.
I recently moved from a bleeding edge C# house to a C# house that was running mostly on dot.Net 1.1 and some 2.0 projects, using mostly only 1.1 features. Luckily management stay away from the code. Most of the developers love all the new features in the newer frameworks, they just don't have the time or inclination to figure them out by themselves. Once I managed to show them how they can make their own lives easier they started using them by themselves and we have migrated several projects to gain the new language features and better tool advantages.
Some people are just afraid of change, because maybe you'll make them all look stupid using fancy new technologies. Could also be that your boss doesn't want the team learning new things instead of getting work done the old fasioned way.
The var keyword can certainly be abused, but in most cases reduces redundant code. LINQ is the main thing you want from .Net 3.5 because of the huge time saving in the amount of code you have to write. Your boss should be encouraging you to use it. Also the base class libraries now take delegates are parameters, so you will be limiting yourself a lot by not using them. Lambda's are just some fancy syntactic sugar to make delegates cleaner.
I would refer you to Effectively Integrating into Software Development Teams and Leading by Example. Two really great articles on how to deal with teams that are afraid of change.
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/
If you were going to start building web sites as a consulting business on the side -- keeping your day job -- and you also had a toddler and a wife, what frameworks/tools would you pick to save you typing?
Any language.
I'm looking for a productivity superstar stack that won't tie my hands too much when I have to update the site 6 months later, or "evolve" the data model once in production.
It needs to allow me to say "yes" to the client: community features, CMS, security, moderation, AJAX, ...
I would suggest Django. Super simple to get something up and running really quick. You are using Python which has a large library to go with it. For me Ruby on Rails would be a close second.
I'd probably look at DotNetNuke. Its easy to set up (a lot of hosts will do it for you) and easy to use and put together a custom site that business's will be able to maintain in the future.
Its fairly easy to create custom modules that are specific to a business and hundreds of modules for sale (or free) that can be integrated into DNN for special uses.
Take a look at Microsoft's Sharepoint server if you'd like a pre-made framework with many options for plugging in your own code. Sharepoint is kind of a world unto itself but it is a very powerful environment.
Update: I'm surprised to have been voted down on this one. Keep in mind that the questioner specifically requested frameworks that included a CMS. Sharepoint meets this criteria - unlike straight .NET or other web development frameworks.
If you are going to vote the entry down, I think you owe it to the person who asked the question to explain why you don't think he should not even explore it as an option. You could be right - collective wisdom is what voting on SO is all about. But without an explanation, we don't know why you think you are right.
My answers are going to revolve around the .NET stack.
Use Master pages and CSS templates. This makes it so much easier to pop in a new look and feel for your customer.
For sure I'd include the Dynamic Data framework in the .NET world.
Hosting might become an issue for your customer. Questions around managing email addresses, procedures on how to quickly update the website to include the new contact phone number (different for each customer, I'd assume) Consider getting a reseller account on your favorite webhost, and dole out webhosting accounts as appropriate. There are lots of issues around this point. It may turn out to be a nice source of recurring revenue.
Build yourself a few patterns including a database wrapper which would handle all your data calls (i.e. a dll which wraps all your data calls, sets up your ADO.NET objects, runs your sproc calls, and picks up the connstring from app.config or something similar.)
This goes a long way to maintainability as well.
I would recomend going with anything MVC in a language you can undertand! Theres a couple of CMS's in python, php and ruby using that design and well... that allows you to be ready for combat for Ajax and expanding anything very fast.
This is definitely not a question that can be answered.
I prefer asp.net webforms because I think it allows for extremely rapid web app development, but I am sure you will receive recommendations for:
asp.net mvc
Ruby on Rails
PHP and some framework
Python and some framework such as Django
I believe PHP has the most pre-built apps that you can use, though asp.net also has the things you are looking for.
All of these platforms and frameworks can do what you want.
Choose between Rails and Django. They both have different strengths. I like Rails better in general, but Django's admin interface can save you a lot of time when you need it.
There's another factor to take into consideration here: what are you the most familiar with? I believe that some studies have found upwards of a 30% loss of productivity when trying to learn a new language/framework.
Sometimes, there's nothing wrong with just sticking to what you know. But if you're interested in what languages/frameworks to learn, I'll refer you to the other posts because the above was the only thing I really have to add.
I recommend looking into Grails. It uses Groovy which is similiar to Java (so if you know this already you're good to go). Groovy runs on the JVM so you can still use all the great libraries already available for Java. Yet, since it's a dynamic language with a lot of the similar bells and whistles like Ruby you can use closures and that kind of neat stuff when you need/want to. And you're not slowed down by Java's traditonal slow compile-deploy-test development cycle.
Grails is already setup with Hibernate and Spring. You can create CRUD application in practically no-time (pretty much like Rails applications), and at the same time drill down and be able to control every little details since it's built on such proven and well-supported technologies. In addition there's literally hundreds of plugins available that helps you easily set up things like mailing lists, security, AJAX components and so on.
Otherwise, if you want to set up a community site and don't want to code a single line you could always check out ning.com.