I care. It is plain ugly. In this case there is no use in having two URI's pointing to the same resource. When people can, they will keep links around to the URI including the aspx bit. Which means that all those links go broken should I change the default to index or whatever. Having the default.aspx bit reveals details about the implementation that are totally irrelevant to visitors. And those details do not serve any purpose other than increasing the burden of changing the technology stack implementing a site and that means increasing the lock-in with that technology (in other words: increasing the inertia with regard to changing it). Pretty url's do not exist for the sole reason of being pretty...

--- http://softwareonastring.com

Assuming DataAccess is a static class, you are in for a bit of work. I can think of several approaches, all of them boiling down to some form of dependency injection without going as far as trying to shoehorn an IoC container into your existing code. One approach that could work: 1. Create an IDataAccess interface. Give it all the methods your DataAccess class currently has to provide your business entities with their data. 2. Remove the static specifier from your DataAccess class and make it an implementer of the new IDataAccess interface. 3. Create a new static class, for example DataAccessLayer and give it a single method, for example: Current(). Implement that method to return an instance of the DataAccess class as an IDataAccess interface reference. It is up to you to create a new instance for every call or to create a single instance and return that all the time. 4. Give every business entity a property of type IDataAccess. (They do all derive from some base class I hope?) Name it DataAccess. As it is closer in scope than anything outside of your business entities any method in those entities referencing DataAccess should now use the interface property instead of the DataAccess class. 5. Implement the DataAccess property getter of your business entities in such a way that it can returns the DataAccessLayer.Current IDataAccess interface reference, UNLESS a private IDataAccess _DataAccess member is non-null. In that case return the member reference. 6. Give all your business entities an extra "InitalizeDataAccess" method taking an IDataAccess parameter. Implement it to assign whatever is passed in to the private _DataAccess member. 7. Use the InitializeDataAccess method in your tests to provide your business entities with an IDataAccess implementer (DataAccess fake) that provides the business entities with data as needed by your tests.

--- http://softwareonastring.com

While a for loop may perform better, a foreach loop reads better and is less prone to off-by-one errors. That is why I have come to prefer them everywhere except _proven_ performance bottlenecks.

foreach (Student currentStudent in studentarraylist)
{
Console.WriteLine("Student {0} {1}", currentStudent.FirstName, currentStudent.LastName);
}

--- http://softwareonastring.com

It is. Thanks!

--- http://softwareonastring.com

What I noticed is that in Chrome the links don't show up when your browser window is wide enough. They do show up when you resize the window below a certain width. In Firefox the links show regardless of the window's width. Hope this can help in resolving the issue.

--- http://softwareonastring.com