/// <summary>
/// Logs user in/authenticates against StockTrader database.
/// </summary>
/// <param name="userid">User id to authenticate.</param>
/// <param name="password">Password for authentication</param>
public AccountDataModel login(string userid, string password)
{
//Create instance of a DAL, which could be designed for any type of DB backend.
dalCustomer = Trade.DALFactory.Customer.Create(Settings.DAL);
//As feature of the StockTrader DAL, you will see dal.Open, dal.BeginTransaction, dal.CommitTransaction,
//dal.AbortTransaction and dal.Close methods being invoked in the BSL. The pattern within this BSL is:
//a) Create an instance of the DAL;
//b) Open the DAL;
//c) Start a transaction only if necessary (more than one update/insert/delete involved);
//d) You get to pick ADO.NET transaction or System.Transactions or ServicedComponent, it will work with
// all of the above; StockTrader lets you choose ADO.NET txs or System.Transactions via config.
//e) Close the DAL. This releases the DAL's internal connection back to the connection pool.
//The implementation "hides" the type of database being used from the BSL, so this BSL will work
//with any type of database you create a DAL for, with no changes in the BSL whatsoever.
//System.Transactions and SQL Server 2005 and above and Oracle databases work together
//with a new feature called "lightweight transactions"; which means you do not need to have the
//same performance penalty you got with Serviced Components for always invoking the tx as a full
//two-phase operation with DTC logging. If operating against a single database to SQL Server or Oracle,
//across one or more connections involved in a tx, System.Transactions will not promote to a DTC-coordinated tx; and hence will be much faster.
//If there are mulitple databases or multiple resources (for example, MSMQ and a database)
//used with a System.Transaction tx, on the other hand, the tx will be automatically promoted to the required distributed tx, two-phase commit
//with DTC logging required. Our StockTrader DAL is designed to:
// 1. Hide DB implementation from BSL so we maintain clean separation of BSL from DAL.
// 2. Let you freely call into the DAL from BSL methods as many times as you want *without*
// creating new separate DB connections
// 3. As a by-product, it also helps you use ADO.NET transactions without worrying about
// passing DB connections/transaction objects between tiers; maintaining cleaner separation
// of BSL from DAL. If using ADO.NET txs; you can accomplish DB-implementation isolation also with
// the Provider Factories introduced with ADO.NET 2.0/.NET 2.0: see for details:
// http://msdn2.microsoft.com/en-us/library/ms379620(VS.80).aspx
//Note Open() is not really necessary, since the DAL will open a new connection automatically
//if its internal connection is not already open. It's also free to open up more connections, if desired.
//We use Open() to stick with a consistent pattern in this application, since the Close() method IS
//important. Look for this pattern in all BSL methods below; with a transaction scope defined
//only for operations that actually require a transaction per line (c) above.
dalCustomer.Open(Settings.TRADEDB_SQL_CONN_STRING);
try
{
return dalCustomer.login(userid, password, Settings.USE_SALTEDHASH_PASSWORDS);
}
catch
{
throw;
}
finally
{
//Always close the DAL, this releases its primary DB connection.
dalCustomer.Close();
}
}