ASP.NET Application Suite Development - Gotchas

Question

This may sound a bit general, but I have a startup that is working on an ASP.NET (greenfield) suite of software applications. We are aiming to spend a substantial amount of time in the architecture phase to develop a strong foundation for our software. I was wondering if anyone has any advice, anything we should focus on or any suggestions for areas we should focus on to build a better suite.

Some things we are focusing on right now: 1. Session state requirements - should sessions be sticky or should we take server clustering session migration into account. 2. User login authentication - what are the major concerns in this space - LDAP, AD, custom SQL authentication systems etc. 3. The DAL - ORM vs Stored Proc
4. Integrating multiple ASP.NET applications in a single software suite. How it should look/feel. How it should be architected, etc.

I would appreciate any advice from any architects out there that have built similar systems from the ground up.

Answer 1

Some general thoughts. If you'd like me to expound on any of these, let me know.

• Inheriting from a custom subclass of Page instead of Page itself is a great way to share functionality across your site.
• Nested MasterPages are good.
• Charting: I've tried DevExpress, Syncfusion, and MSChart control and all have their own issues.
• The built-in forms authentication is pretty good. Building a site that allows both integrated authentication and forms authentication is tricky but can be done.
• I've tried using cross page postbacks and I'm still not sure if I like them.
• Localization takes a lot of time
• Come up with a good structure for your App_Themes and css.
• Use Elmah to track unhandled exceptions

Answer 2

Just some quick notes. I can't get too detailed since we went through this exercise where I worked last year - and I don't work there any more!

• Start from the beginning using Enterprise Library, especially the Logging and Exception Handling application blocks. I've also found their Unity dependency injection library to be very useful.
• Consider using Visual Studio Team Foundation Server. It's not just for source control, but can create you a complete continuous integration solution, complete with integrated bug tracking, code quality tracking, etc. If you've got the time and people, it's well worth a man-month to learn how to do an initial deployment.
• You may want to buy one or more licenses of one of the Visual Studio Team System editions. You don't need these versions in order to use TFS, but they work well with it.
• Consider globalization right from the start. Same with customization, if your suite will run on customer premises and be customizable by them.
• You haven't said how large your team is, or is expected to be. If it's large enough, you'll want to spend at least a man-week learning a bit about what's available to you in terms of Visual Studio Extensibility. Your developers (and maybe also your QA folks) will all but live in Visual Studio, so the ability to customize it to meet your needs can be a big win. Whether it's just some macros and maybe some customized project or item templates, or whether you want to do add-ins or more, Visual Studio is very extensible.
• Be certain to use WCF for any web services work. The older ASMX web service technology is now considered by Microsoft to be "legacy software".
• Finally, be sure to find out whether you qualify for BizSpark, "A program that provides Software, Support and Visibility for Software Startups." And does so almost for free.

Answer 3

I saw a demo of Silverlight 3 at the PhillyDotNet User Group last night - WOW. Wow for business applications, not graphic applications. There is a learning curve, but you get a lot for it. For example, the demo showed a grid being bound to a table without needing to write any code.

Right out of the box you had sorting, editing, paging, etc. But it wasn't the lame stuff you normally get and then have to rework. For example the paging was smart enough to write the sql that would only bring back the 20 rows you needed for the page.

The demo continued with him putting a detail form on the page for editing. Again no code, but it was smart enough to know that it had the same datasource as the grid on the page. So as you were moving row to row on the grid - the detail form was showing the current row (and it was very fast).

Both the grid and the detail form were editable and as you changed a field in one the other would reflect the new value. The editing was smart enough to validate the field on its own. So you couldn't put a letter in a field that was an integer type, etc. It also limited the number of characters that could be entered based on the column size found in the database. All the date fields on the detail form automatically had a calendar next to them. You get the idea - no coding for any of this.

If this weren't enough, it can be used to build occasionally connected applications. So he showed how he updated a few records on a few different pages, had the option to revert back a field later (ctrl-Z), and then at the end submitted all the changed records to be saved.

Also, they said it works with Linq2SQL and the entity fraimwork.

So if I were building a new product now, I would really look into this as a way of differentiating my product. And I suspect that if you don't do it with Silverlight now, you will be rewriting it in a few years anyway.

Here is a link to a demo (not the one I saw.)

Answer 4

I know there are lots of solutions to session, but if you can create your framework to be session-free, you will avoid a lot of potential headaches. (There are lots of session-free options, but an obvious one is a hidden form field, somewhat like ViewState.)