On the right you find the complete list of articles published on this Web site conveniently split up in pages.
If you want to narrow down the list, click a sub category from the sub menu.
|1/8/2014 10:22 AM|
Note: this is part one in a series of ten. If you rather read this entire series off-line, you can buy the full series as a convenient PDF document that comes with the full source. Besides the convenience, buying the PDF will also make you feel good as it shows your appreciation for the articles and helps me pay the bills for my server and hosting so I can keep running imar.spaanjaars.com and continue to provide you with great content. For more details, check out this post that shows you how you can buy the entire series right now.
Now that the RTM versions of Visual Studio 2012 and .NET 4.5 have been out for a while, it seems like a good time to finally write the follow up to my popular series on N-Layered design using ASP.NET 3.5 that I wrote in 2008 and early 2009. I have been wanting to do this for a long time, but there were always other things on my Todo list with a higher priority. The wait has been worth it though; since the last series targeting .NET 3.5 that I published in late 2008 and early 2009, new and compelling technologies have been released that make writing an N-Layered application such as the Contact Manager a lot easier to write.
A question that comes up often on forums such as p2p.wrox.com is how to let users manage their own data stored in a database. Probably the easiest way to accomplish this is to keep the user name in a separate column. Then when you query the data, you add a WHERE clause that retrieves only those rows that matches the user's name. Likewise, when inserting data, you store the user name along with that data.
But how do you capture the user's name? In the remainder of this article you see a two different ways to retrieve the user name of the currently logged in user.
By design HTTP, the protocol used to request and deliver web pages, is stateless. What that means is that the server does not keep track of requests you made to the browser. As far as the server is concerned, each request for a page is an entirely new one and is not related to any previous request you may have made.
This of course causes issues if you need to maintain data for a specific user. To overcome these problems, web developers have a number of solutions available, including session state, cookies and hidden form fields. ASP.NET Web Forms has been hiding much of this complexity by implementing a concept called View State. Controls (including the Page class itself) can read from and write to the View State collection to maintain data across postbacks. Controls such as Label use this mechanism to send their values to and from the browser, maintaining them across postbacks.
In this article you'll see how to leverage View State to store your own values as well.
Over the past couple of weeks I received a number of e-mails from readers with more or less the same question: how do you require users to confirm their e-mail addresses before they are allowed to log in with an account they just created. Rather than answer them individually by e-mail, I decided to write this article to explain the principles.
The CreateUserWizard control in ASP.NET makes it super easy for your users to sign up for an account. Simply add it to a page, configure it, and you're good to go. In addition, you can control the way it behaves using settings in the web.config file (such as whether or not duplicate e-mails are OK, password lengths and strength, whether or not you want to implement a "security question and answer" and so on). Also, when you don't like its appearance, you can customize the wizard's steps which expands its underlying HTML into your page, so you get full control over the rendering.
However, when you customize the steps, you'll find that the config setting that controls the display of the "security question and answer" no longer works as expected. In this article you see how to set up your control so it still takes the config settings into account.
Over the past weeks I received a number of requests to explain how I typically set up my Visual Studio projects so they are easy to manage across a team that uses Team Foundation Server (TFS). I received another request from a client just this week and instead of helping him over the phone or paying him a visit and do it for him, I decided to write a quick document with instructions which eventually resulted in this article.
In this article you'll see how to create a multi-project solution in Visual Studio. I'll show you how you can use this structure to set up an ASP.NET MVC 3 application with a separate class library project for business logic and one or more unit test projects. However, you can use the exact same principles for other types of Visual Studio projects such as Web Forms, Win Forms, WCF and more. Over the past years, I found that this set up brings me the following benefits:
This is just my take at setting it up. If you find anything wrong, or have better alternatives to accomplish the same thing: feel free to speak up using the Comments section at the end of this article.
Without further ado, let's get started.
Some time ago I was involved as a software designer and developer in an MVC 3 project that used Entity Framework Code First 4.1 in a repository layer. During development we postponed dealing with security as requirements were pretty simple (simple logons with a single Administrators role plus the requirement that users should only be able to see their own data). When we were close to deployment, we ran the aspnet_regsql tool against the database that EF had created for us to create the SQL schema and data that the Application Services such as Membership and Roles require. We also added an additional userName parameter to a Get method in the repository to filter records for the currently logged in user. Finally, we added Authorize attributes to a number of controllers to make sure they are only accessible for users that are logged in. We then deployed the application and database, created a number of users using the MvcMembership section we had added to the site, and announced the presence of the site. All of this worked great, but we ran into issues when started work on the next version of the application.
Some time ago I received a question on the Wrox P2P forum about checkboxes that should behave like radio buttons. The poster of the question was looking for a (client side) solution to have multiple checkboxes per row in a GridView with multiple rows. A user should only be able to check off at most one of the checkboxes in each row. My first thought was to use radio buttons instead, but then I realized that with radio buttons you lose the ability to uncheck all options. Once you've selected a radio button in a group of radio buttons, there's no way for an end user to uncheck it again.
Fortunately, with a bit of jQuery, this is really simple to accomplish with checkboxes as I'll show you in this short article.