.NET Solution Structure

October 26, 2005

So for the next gen of our ASP.NET based software platform, which we’ll build on .NET 2.0 w VS.NET 2005, here are some key components:

  1. MS SQL database, we’ve borrowed the naming scheme from Rails—why not?
  2. Historically we’ve done a lot of work inside SQL queries (a LOT of work)—we’ll move away from that practice in the interest of centralizing business logic into the business tier (which sits above the DAL and below the app)
  3. After investigating the use of O/R Mappers vs. DAL code generators, we decided to “roll our own”—we build a C# application that generates a basic class for each table with CRUD + collection operations. Everytime we change the DB, we’ll have to regenerate the DAL, but no longer will we need to make manual code edits in that layer.
  4. The app layer (web app, web service, desktop app) will deal with presentation details only—we’ll refactor rigorously to push business logic down to a shared business layer.

We may build a web helper project for presentation code that is shared among web projects.

As a result of all this, we’ll have a thick shared business layer—but we’ll have all the “complicated” code in one project, with it’s goal being to make the code in the app layer as readable + simple as possible.

Update: We dumped our custom coded DAL in favor of .NET 2.0 Strongly-typed data sets. Working good so far.