Scenario: R&D area in a small voice&data carrier. Being a telco, we consider ourselves a heavy UNIX (& Java) shop. We’ve developed many in-house tools and applications in unix, java and some script environments which work reliably and reasonably well. Actually, these systems are mission-critical components in our company’s revenue chain, and we’re quite happy with them.

In such a scenario, why would we want to try .NET in our next project – a web-based telco billing app?

Our new project constraints:

• Short time-frame for development: Our current platform is causing lots of organizative problems and has many technical shortcomings, so we do have to get rid of it as soon as possible.
• Our app should have a heavy, rich and responsive web-based ui. We have branch business offices over all the country, but only a central location with 24×7 support, disaster recovery facilities and a really good datacentre infrastructure, so going Web seems natural for us.
• We’re a very small team (4 people).
• Our app has to be very scalable.
• Our app has to be easily maintainable. In the past the company invested a lot of time and money in tools which finally we weren’t able to maintain and extend. Thus, we emphasize in having a loosely-coupled well-defined architecture which doesn’t compromise current or future needs.
• It is a critical app, but not a 24×7 app: if our app isn’t available during five minutes we don’t lose any income. That isn’t the case of many of our other in-house unix&java applications!

Having these constraints we could have gone the Java way, but what kind of Java way?

• Traditional J2EE+Struts stack? No Way. We’re three people here, so we have no time to spend creating lots of XML, deployment descriptors, JSPs and all these dot-com-era artifacts. Also, we wanted to use a component-based UI development. Developing in such enviromnet would have been so 2000′ish…
• New JEE 5? No way. When we started our project (June ‘06) it was simply not mature enough. Also, the tooling it has isn’t good enough for considering it real RAD. JPA is quite limited, too. In addition, while JSF is component-based, developing custom compound components for it is a real pain.
• Alternative frameworks (Spring+Hibernate+Wicket/Tapestry/Echo2)? This was a good option. I really like Spring (not as MVC fr., tought) and Hibernate. In fact, sometimes when I suffer from VS2005’s instability, I wish I had choosen this path. But one of our constraints was that we had a short time to market,and these UI frameworks require heavy investment in development time to create the rich components we’d need. Had we have more time, I’d probably have choosen this path, in order to develop our custom rich ui components instead of buying them from 3rd parties (telerik rocks). It’s a pity there isn’t a market of commercial components for – at least – Tapestry or Wicket.

We could also have gone the scripting way, but… which one?

• PHP5+PRADO (http://www.pradosoft.com): We have used this in some other (smaller) projects. Devel time is quite good, and the PRADO component-based framework allows following an easy development workflow for the UI. But what about the back’end? PHP ORM tools are very simple and I don’t like any of them. The one I’d like the most (EzPDO) has a ‘feature’ which makes me forget about using it: it uses custom tables for relationship, instead of trusting DB foreign keys. Then we tried code-generating a DAO layer. We achieved a good level with custom code-gen tools, but that wasn’t a real ORM. Right now, we don’t conceive developing our app without an ORM, so we finally had to discard PHP.
• Ruby on Rails? Let me check… not component-based UI, not real ORM (ActiveRecord pattern is great but not real ORM)… scaffolding doens’t work with foreign keys and inheritance (our custom code-gen tool does)… discarded

So, we finally came up with a solution which – more or less – is what we’ve been looking for:

• .NET Framework 2.0
• ASP.NET
• NHibernate (!!)
• SQL Server 2005 (including Reporting Services)
• Spring Framework.NET (!!!!!)
• Telerik Component Suite (!!!!!!!!!!!!!!)
• MSMQ (async processing)
• Java-based custom code-gen tools

We’re really happy with this environment.

I don’t like traditional .NET architecture, it seems ackward if you’re coming from a Java background. But I really like ASP.NET’s component model. It’s easy to understand, and it’s very easy to develop components on it.

In addition, C# 2.0 is good enough. I preffer Java 1.5 (I hate having to declare methods virtual all the time), but C# 2.0 has really good generics support, and delegates are good too (I still preffer anonymous classes, but).

By using Spring.NET we’ve achieved a very loose coupling between layers. By using NHibernate, we’re coding against an object domain model and not against a relational model. We’ve also achieved 97% database independent code (still some SQL in a few modules). And we have a rich domain model which hasn’t any pollution (persistence code, forced inheritance).

By using Telerik Component suite, the person which develops the UI here has been able to create really good screens. Our app is very responsive and easy to work with.

By using SQL Server 2005 we get a quite good database. I don’t like the fact that it hasn’t deferrable constraints, but its partitioning feature is quite good. Also, analysis services and reporting services are a bonus we’re happily taking advantage of.

Finally, MSMQ is a good-enough easy-to-use JMS-alike message oriented middleware, which we use for async, deferred and/or scheduled processing. We’ve suffered from some annoying .NET generic collection serialization problems, but these have been solved easily, and in the future we’ll try to enlist SQL 2005 and MSMQ transactions in a global transaction to achieve almost-JTA reliability.

So, we’ve sold our soul to the devil. We’re Unix&Java guys who have gone the .NET way! I guess our app won’t scale the same as a Java solution would. Also, our app has been developed from scratch… it doesn’t need any integration to legacy datasources, two-phase commits, strange messaging integrations or connecting to foreign EIS’s. If it needed such features, going .NET would have been insane.