Reply to: .NET technology stacks for web apps

[doodab]

Personally on the Java side I'm quite happy using servlets+JSP/JSTL and writing DAOs so I don't fundamentally disagree about using new tech. On a small project I wouldn't use all that enterprise stuff probably unless I wanted to use it for the experience.

But as the last poster says, you have to be aware you're thinking this way lest you end up inflexible. You see people who refused to learn Java and JSP because C++/CGI or VB/ASP "worked just fine". It's a bit of a tightrope act to be open to new technologies without hopping from fad to fad.

I'm lucky in that I usually have a lot of leeway to do things how I see fit. I do try to weave new things into what I'm doing as and when they appear to be useful and getting widely adopted, but I avoid jumping on every new thing that comes along, simply because I know 90% of it will fall by the wayside. Generally I decide whether something is worth my time based on whether it seems simple, well thought out and easy to get to grips with, and avoid anything that seems to make life unnecessarily complicated. I'm basically lazy.

[d000hg]

Personally on the Java side I'm quite happy using servlets+JSP/JSTL and writing DAOs so I don't fundamentally disagree about using new tech. On a small project I wouldn't use all that enterprise stuff probably unless I wanted to use it for the experience.

But as the last poster says, you have to be aware you're thinking this way lest you end up inflexible. You see people who refused to learn Java and JSP because C++/CGI or VB/ASP "worked just fine". It's a bit of a tightrope act to be open to new technologies without hopping from fad to fad.

[eek]

Maybe I'm a burn out. Been doing this so long I no longer get excited when a new technology comes along. Especially when they appear to me convoluted and just add another layer to achieve the same thing as the older tech.

You should be careful what you say as following that argument to its logical conclusion Classic asp is acceptable for the job.

I think the problem here is that it depends on what the purpose of the website is. To provide information to internal users webforms are fine. If its going to be accessed by the outside world and you want tons of ajax on it to make it all singing all dancing then MVC will be a better bet.

It does seem to be a lot of extra work tho.

[PAH]

MVC is a pattern not a library.

I meant MS's current implementation of MVC as an alternative to their existing ASP.Net webforms.

I can see where MVC is likely to be highly regarded as the better approach, in Agile environments where a test based approach is preferred.

Learning technologies isn't a waste but laying your reputation only on what libraries you know is. You will find work as a good developer who only knows the 'boring' parts but you will miss some opportunities at the same time. Nobody can know everything and ultimately you have to make choices. As much as anything it depends if you LIKE learning stuff and playing with it, or just want to be able to create production code and get paid for solid work.

Maybe I'm a burn out. Been doing this so long I no longer get excited when a new technology comes along. Especially when they appear to me convoluted and just add another layer to achieve the same thing as the older tech.

e.g. every solution I've worked on in the last 10 years required getting data out of a database and displaying it on a web page. While that data is in a SQL database and the front end requires HTML as it's core I prefer to keep it simple. Besides I can do in one day using my old tech what it takes other people days or weeks to do in the new stuff, when you take into account the time they spend tracking and fixing bugs, and having meetings about burning down stuff. Who's agile now.

Maybe this new stuff is about job creation and keeping bob at arms length. That would explain a lot. I just prefer the simple/easy life.

[d000hg]

I'd be wary of getting into newish MS technologies that may turn out to be fads.

I'm not yet convinced any of the following will still be around in 5 years:

MVC, Entity Framework, Silverlight

MVC is a pattern not a library, it's used in many/most modern in-vogue libraries across the board... including heavy-weights like Spring. So learning the idiom is not a waste whatever. As for Silverlight well this is unclear. It is the key way to write apps for Windows Mobile but the desktop direction of MS is uncertain with different claims being made.

Learning technologies isn't a waste but laying your reputation only on what libraries you know is. You will find work as a good developer who only knows the 'boring' parts but you will miss some opportunities at the same time. Nobody can know everything and ultimately you have to make choices. As much as anything it depends if you LIKE learning stuff and playing with it, or just want to be able to create production code and get paid for solid work.

[escapeUK]

I'd be wary of getting into newish MS technologies that may turn out to be fads.

I'm not yet convinced any of the following will still be around in 5 years:

MVC, Entity Framework, Silverlight

I stick to the core technologies that have been around for the best part of 10 years or more (ASP.Net with web forms, C# or VB.Net, and SQL Server using stored procedures). Strange how the apps I write and maintain using those are quicker to build, less complex, more stable, and easier to maintain than those using the newer 'reinventing the wheel' technologies.

Maybe I'm just bored of having to learn new technologies every ~2 years when they don't really offer much reward.

I agree 100%. It wouldn't be so bad if the new technologies were actually faster. But every new data access technique from Microsoft is slower than the previous one.

[woohoo]

I would go with MVC 3 and Razor. Try out code-first development with entity framework, I think it's still at ctp stage but looks really promising. Just design your domain model then let it generate the database (with a little tweaking), though Ive not put anything into production with it yet. Otherwise using Linq to SQL its pretty easy to knock up a data access layer. Looks good on the CV anyway.

Not sure about MVC being a fad, the pattern has been around for a while, just MS went down a different path and are just catching up now. Anyway clients are asking for it now so its worth learning in my humble opinion.

[eek]

WHS!

+1

Silverlight already seems to be quietly being killed off (note how little interest was shown at last years developer conferences).

Entity framework is nice but any of the ORM systems are fine at removing databases from the issue. Granted I hate llbgen pro as I've had serious explained issues with it on a system I inherited but they do perform a decent job (unlike linq which I ranted about earlier).

MVC I'm unsure about as it does separate business logic totally from the presentation layer. However I remember a presentation on frameworks for php and mod_perl doing the exact same thing 10 years ago and they never took off.

It could be a fad but if you have to support three different types of devices (computers, tablets and mobiles) it may have an actual purpose.

Personally give me webforms and a decent code generator (to do the leg work) any day

[2BIT]

I'd be wary of getting into newish MS technologies that may turn out to be fads.

I'm not yet convinced any of the following will still be around in 5 years:

MVC, Entity Framework, Silverlight

I stick to the core technologies that have been around for the best part of 10 years or more (ASP.Net with web forms, C# or VB.Net, and SQL Server using stored procedures). Strange how the apps I write and maintain using those are quicker to build, less complex, more stable, and easier to maintain than those using the newer 'reinventing the wheel' technologies.

Maybe I'm just bored of having to learn new technologies every ~2 years when they don't really offer much reward.

even though the article I posted about this is very old it makes the same point, where is the value in learning a framework that will be superseded soon

[2BIT]

I'd be wary of getting into newish MS technologies that may turn out to be fads.

I'm not yet convinced any of the following will still be around in 5 years:

MVC, Entity Framework, Silverlight

I stick to the core technologies that have been around for the best part of 10 years or more (ASP.Net with web forms, C# or VB.Net, and SQL Server using stored procedures). Strange how the apps I write and maintain using those are quicker to build, less complex, more stable, and easier to maintain than those using the newer 'reinventing the wheel' technologies.

Maybe I'm just bored of having to learn new technologies every ~2 years when they don't really offer much reward.

WHS!

[StopTheEarthIwantToGetOff]

NHibernate using the relatively new Fluent Fluent NHibernate mapping method for your datamodel.
Using the two above you can get all the data persistance stuff out of the way in a matter of minutes. Plus Fluent NHibernate does away with all the fiddly xml config files or code attributes (you also get compile time validation of your mappings, which can save a lot of wasted time in my experience)

Using a powerful ORM like NHibernate gives you database independence as you just change the configuration to point to a different database type.

Use Ninject Open source dependency injector for .NET - Ninject if you need a dependency injector

MVC is the way to go for ASP.NET apps these days. Probably best to use RAZOR Introducing for your view engine as its very easy to use and get into.

All the stuff I mentioned is open source, so no licensing issues.

Hope this is of use.

[PAH]

I'd be wary of getting into newish MS technologies that may turn out to be fads.

I'm not yet convinced any of the following will still be around in 5 years:

MVC, Entity Framework, Silverlight

I stick to the core technologies that have been around for the best part of 10 years or more (ASP.Net with web forms, C# or VB.Net, and SQL Server using stored procedures). Strange how the apps I write and maintain using those are quicker to build, less complex, more stable, and easier to maintain than those using the newer 'reinventing the wheel' technologies.

Maybe I'm just bored of having to learn new technologies every ~2 years when they don't really offer much reward.

[fullyautomatix]

Current method of choice would be an ORM (entity framework, nhibernate) for persistent storage and MVC for the asp.net level.

So mvc templates for the frontend
mvc containers calling business layer objects for the logic layer
orm for the database

In an ideal world you then have nunit for test around everything and some mocking system for everything else.

As its a plan b tho scrap the detailed plan above and use codesmithtools or something to generate a plingo start point CodeSmith Tools and create standard asp.net pages .

MVC or WebForms. Although MVC is very good for test driven application, Web forms are really good for RAD.

[2BIT]

It's an ingenious solution to the problem of moving your business logic out of the database and into the business tier, while still writing it in SQL.

wasn't that what you did with ADO?

[thunderlizard]

It's an ingenious solution to the problem of moving your business logic out of the database and into the business tier, while still writing it in SQL.