Common patterns / practices for domain objects and object-relational impedance mismatch?

We're currently developing domain layer for our company's intranet. Basically, we follow a simple and well defined N-Layer pattern from series of articles by Imar Spaanjaars.
We are porting of an existing classic ASP application to ASP.NET 3.5 / C# / SQL Server 2008 environment. Because of that, both business logic and a database are pretty much defined. What we need, however, is some additional guidance on overcoming object-relational impedance mismatch, common design patterns / practices for domain objects which correspond to database objects (tables) with one-to-many, many-to-many, and look-up types of relationships.
Which books/articles would you recommend to read?

Using HttpModules and HttpHandlers under IIS7

IIS 7 uses by default a new Integrated type of Application Pool. Old style Pool called Classic is available as well. As I discover after some trouble, to use HttpModules and HttpHandlers in ASP.NET application running under Integrated Application Pool, one need to add additional lines to Web.config file.
Normally, you put HttpHandlers and HttpModules sections inside system.web section.
To work under Integrated Application Pool, Web.config should put modules and handlers sections inside system.webServer section:

<configuration>
  <!-- This is for Classic Application Pool -->
  <system.web>
    <httpModules>
      <add name="IntranetPageHttpModule" type="CoTs.Intranet.IntranetPageHttpModule" />
    </httpModules>
    <httpHandlers>
    </httpHandlers>
  </system.web>
  <!-- This is for Integrated Application Pool -->
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <modules>
      <add name="IntranetPageHttpModule" type="CoTs.Intranet.IntranetPageHttpModule" />
    </modules>
    <handlers>
    </handlers>
  </system.webServer> 
</configuration>

References:


ASP.NET Integration with IIS7 by Mike Volodarsky, page2.


HttpModule and HttpHandler sections in IIS 7 web.config files - Rick Strahl's Web Log

Design time support for custom properties of a custom ASP.NET base page?

I'm converting to ASP.NET an ASP project in which each page has its own ControlNumber string, used as a page unique identifier. The whole security model is build around using those ControlNumbers.
On ASP pages ControlNumber are set simply as a constants:

const ControlNumber = "blah-blah"

In ASP.NET I would like to implement a page ControlNumber as persistent BasePage public property, which could be set in VS at design time.

It's easy to inherit BasePage from System.Web.UI.Page, but how to add persistent property, visible in VS at design time?

Did C# borrow ideas from JavaScript?

I have just read a good article by Scott Hanselman about internals of Extension Methods. I felt for a long time that C# is borrowing more and more features from JavaScripts. Things, like 5.ToString() (.Net object types behind all simple types), anonymous class initialization, array initialization {1, 2, 5} - all these exist in JavaScript for a long time. Then - type inference (with "var"). Finally: an article mentioned above shows that extension methods implement something similar to JavaScript prototype functionality. (I know about functional programming, Ruby and Scala.)
What do you think?

Use public Collection<T> instead of public List<T>

The Visual Studio Code Analysis Team Blog: Why does DoNotExposeGenericLists recommend that I expose Collection<T> instead of List<T>? (See comments under part 2 of Imar's article) as well.

Microsoft: Glasnost and Perestroika

Isn't it funny? And this comparison of Microsoft and Hillary Clinton too...