View Single Post
Old April 24th, 2008, 08:53 AM
planoie's Avatar
planoie planoie is offline
Friend of Wrox
Points: 16,481, Level: 55
Points: 16,481, Level: 55 Points: 16,481, Level: 55 Points: 16,481, Level: 55
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
Join Date: Aug 2003
Location: Clifton Park, New York, USA.
Posts: 5,407
Thanks: 0
Thanked 16 Times in 16 Posts

One of my original points is that you can build an ASP.NET service provider that consumes your existing business logic. By creating providers you can use the existing ASP.NET controls (login, etc) but they are pointed at your custom provider instead of the default provider in order to use your business logic. You are simply building a bridge (really just replacing the bridge .NET provides natively) between your own code base and the provided .NET functionality. Convey to the boss that your reducing the work, because then you don't need to build the control set to work with you custom logic.

When you login on a form, the credentials are passed as plain text. If you are using SSL then everything's encrypted.

One bit of advice: use Exceptions for situations that are truly exceptions. Closely consider what the outcome will be for your method. In the case of a login, a failed login is an expectable outcome, definitely not an exception. Don't throw an exception for an expectable outcome.

There are a number of cases where I've needed to write a method that should return some data, but might also need to return some status type information regarding the request for the data. A login procedure is the perfect example of this. Instead of a return type of the expected data and throwing an exception when something's different, I create a return args class (similar to an event args class). This will have a property for the expected data as well as the status of the call. So a failed login due to incorrect credentials will be flagged as such and include no data. A successful login will flag as good and include data.

Another approach could be to make a method that takes some callback delegates. One for success and one for failure so there is very clear distinction between the result condition and subsequent action to take. This is a bit more elegant too in that the logic of "what to do when" is handled by the login method instead of by the consumer. The consumer provides the "what" to do and the login method provides the "when".