3 Tier Architecture - In need of an example - asp.net

Presently I am working using single tier architecture. Now I am wanting to learn how to write code using 3 tier architecture. Please can you provide me with a simple example?

Wikipedia have a nice explanation: Multitier architecture:
'Three-tier' is a client-server architecture in which the user interface, functional process logic ("business rules"), computer data storage and data access are developed and maintained as independent modules, most often on separate platforms.
Web development usage
In the web development field, three-tier is often used to refer to websites, commonly electronic commerce websites, which are built using three tiers:
A front end web server serving static content, and potentially some cached dynamic content.
A middle dynamic content processing and generation level application server, for example Java EE, ASP.net, PHP platform.
A back-end database, comprising both data sets and the database management system or RDBMS software that manages and provides access to the data.

This is what I have in my project. More than just a traditional 3-tier architecture.
1.) Application.Infrastructure
Base classes for all businessobjects, busines object collection, data-access classes and my custom attributes and utilities as extension methods, Generic validation framework. This determines overall behavior organization of my final .net application.
2.) Application.DataModel
Typed Dataset for the Database.
TableAdapters extended to incorporate Transactions and other features I may need.
3.) Application.DataAccess
Data access classes.
Actual place where Database actions are queried using underlying Typed Dataset.
4.) Application.DomainObjects
Business objects and Business object collections.
Enums.
5.) Application.BusinessLayer
Provides manager classes accessible from Presentation layer.
HttpHandlers.
My own Page base class.
More things go here..
6.) Application.WebClient or Application.WindowsClient
My presentation layer
Takes references from Application.BusinessLayer and Application.BusinessObjects.
Application.BusinessObjects are used across the application and they travel across all layers whenever neeeded [except Application.DataModel and Application.Infrastructure]
All my queries are defined only Application.DataModel.
Application.DataAccess returns or takes Business objects as part of any data-access operation. Business objects are created with the help of reflection attributes. Each business object is marked with an attribute mapping to target table in database and properties within the business object are marked with attributes mapping to target coloumn in respective data-base table.
My validation framework lets me validate each field with the help of designated ValidationAttribute.
My framrwork heavily uses Attributes to automate most of the tedious tasks like mapping and validation. I can also new feature as new aspect in the framework.
A sample business object would look like this in my application.
User.cs
[TableMapping("Users")]
public class User : EntityBase
{
#region Constructor(s)
public AppUser()
{
BookCollection = new BookCollection();
}
#endregion
#region Properties
#region Default Properties - Direct Field Mapping using DataFieldMappingAttribute
private System.Int32 _UserId;
private System.String _FirstName;
private System.String _LastName;
private System.String _UserName;
private System.Boolean _IsActive;
[DataFieldMapping("UserID")]
[DataObjectFieldAttribute(true, true, false)]
[NotNullOrEmpty(Message = "UserID From Users Table Is Required.")]
public override int Id
{
get
{
return _UserId;
}
set
{
_UserId = value;
}
}
[DataFieldMapping("UserName")]
[Searchable]
[NotNullOrEmpty(Message = "Username Is Required.")]
public string UserName
{
get
{
return _UserName;
}
set
{
_UserName = value;
}
}
[DataFieldMapping("FirstName")]
[Searchable]
public string FirstName
{
get
{
return _FirstName;
}
set
{
_FirstName = value;
}
}
[DataFieldMapping("LastName")]
[Searchable]
public string LastName
{
get
{
return _LastName;
}
set
{
_LastName = value;
}
}
[DataFieldMapping("IsActive")]
public bool IsActive
{
get
{
return _IsActive;
}
set
{
_IsActive = value;
}
}
#region One-To-Many Mappings
public BookCollection Books { get; set; }
#endregion
#region Derived Properties
public string FullName { get { return this.FirstName + " " + this.LastName; } }
#endregion
#endregion
public override bool Validate()
{
bool baseValid = base.Validate();
bool localValid = Books.Validate();
return baseValid && localValid;
}
}
BookCollection.cs
/// <summary>
/// The BookCollection class is designed to work with lists of instances of Book.
/// </summary>
public class BookCollection : EntityCollectionBase<Book>
{
/// <summary>
/// Initializes a new instance of the BookCollection class.
/// </summary>
public BookCollection()
{
}
/// <summary>
/// Initializes a new instance of the BookCollection class.
/// </summary>
public BookCollection (IList<Book> initialList)
: base(initialList)
{
}
}

By "tier" do you mean a "layer" in your software stack? The word "tier" is better used to describe the physical components of your system. If you are using ASP.NET, you probably already have a "3 tiered" system -
Browser displaying web pages
IIS Server hosting your app
Database Server with your database
But you are possibly putting all of your code into a single software "layer" - specifically, the code behind file of your aspx pages. You want to move from a single layer to a 3 layer approach. The classic "3 layer" software architecture consists of the following -
Presentation Layer
Business Logic Layer (BLL)
Data Access Layer (DAL)
(source: asp.net)
For a typical ASP.NET app, you might apply this as follows. First, you create a LINQ2SQL file (.dbml) containing the objects for your database access. This is your Data Access Layer (DAL).
Next you might create a DLL to contain your Business Logic Layer (BLL). This layer will access the database via the DAL, manipulate it as required, and then expose it via a simple interface. For example, if your application displays a client list, your BLL might have a public function called GetClientList() which returned a list of clients.
Finally you would set up your code behind files to instantiate the BLL and wire it up to the interface components. This is your Presentation Layer. For example, it might take the data returned from your GetClientList() function and bind it to a data grid on the web form. The idea is to have the presentation layer as thin as possible.
This seems a little long-winded to describe, but it's pretty straight-forward once you have done it a couple of times. You will find that separating out your application like this will make it much easier to maintain, as the separation of concerns leads to cleaner code. You will also find it much easier to upgrade or even replace your presentation layer, as it contains very little smarts. Finally, you will get to a point where you have a number of very useful BLL libraries that you can easily consume in new applications, greatly improving productivity.

Presentation layer: put everything that is related to user interface. (What the user sees)
Business layer: everything that is related to the logic of the application (How is the information coming from presentation layer treated)
Data layer: provide an abstraction of the underlying data source(s) (Where and how the information coming from/going to business layer is stored)
Each layer should know as less as possible about the other and it should be a top down approach:
the data layer should know nothing about business and presentation
business layer should know about data but not about presentation
presentation should know about business but not about data
Simple example:
Website:
Presentation: all the graphical things, fields where user inserts data, menus, pictures, etc.
Business: all constraints about the data (unique name, name without symbols, valid date, etc), methods for manipulating business objects (create new user, add new order, etc)
Data: Methods that access the underlying database.

3-tier architecture can have different meanings depending on context. Generally it means that responsibilities in the application are divided between different tiers. Typically, 3-tier refers to :
presentation tier" (actual user interface)
logic tier (application/business logic)
data tier (database, data storage)
The details vary by application.
Wikipedia, as usual, has a nice overview: http://en.wikipedia.org/wiki/Multitier_architecture
A simple example would be a typical business app:
presentation: browser, or fat client
logic tier: business logic, typically in an application server (based on J2EE, ASP.NET or whatever)
data tier: a database, typically a RDBMS such as MySQL or Oracle

A 3-tier architecture usually has the following components:
Client Browser
Web server hosting the ASP.NET application
Some backend storage such as database that is being accessed by the ASP.NET application
So to answer your question on how to write code for a 3-tier architecture, you develop an ASP.NET application that communicates with a data storage.

A good tutorial, with complete source control download of a well written tiered application would be here:
http://nerddinnerbook.s3.amazonaws.com/Intro.htm
This isn't a tutorial about tiered architecture, but it's a well written app and gives some insight into why you might consider this architecture.
Additionally, as has only been briefly touched on above, this is about keeping your logic/storage/presentation code separate, so if you have to change one of them (e.g change from asp.net front end to a desktop application), it's not so hard to do.

Three-tier (layer) is a client-server architecture in which the user interface, business process (business rules) and data storage and data access are developed and maintained as independent modules or most often on separate platforms.
Basically, there are 3 layers:
tier 1 (presentation tier, GUI tier)
tier 2 (business objects, business logic tier)
tier 3 (data access tier). These tiers can be developed and tested separately.
What is the need for dividing the code in 3-tiers? Separation of the user interface from business logic and database access has many advantages. Some of the advantages are as follows:
Reusability of the business logic component results in quick
development. Let's say we have a module that handles adding, updating,
deleting and finding customers in the system. As this component is
developed and tested, we can use it in any other project that might
involve maintaining customers.
Transformation of the system is easy. Since the business logic is
separate from the data access layer, changing the data access layer
won’t affect the business logic module much. Let's say if we are
moving from SQL Server data storage to Oracle there shouldn’t be any
changes required in the business layer component and in the GUI
component.
Change management of the system is easy. Let's say if there is a minor
change in the business logic, we don’t have to install the entire
system in individual user’s PCs. E.g. if GST (TAX) is changed from 10%
to 15% we only need to update the business logic component without
affecting the users and without any downtime.
Having separate functionality servers allows for parallel development
of individual tiers by application specialists.
Provides more flexible resource allocation. Can reduce the network
traffic by having the functionality servers strip data to the precise
structure needed before sending it to the clients.

connection class
-----------------------
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Data;
using System.Data.SqlClient;
using System.Configuration;
using System.Web .UI.WebControls ;
/// <summary>
/// Summary description for conn
/// </summary>
namespace apm_conn
{
public class conn
{
public SqlConnection getcon()
{
SqlConnection con = new SqlConnection(ConfigurationManager.ConnectionStrings["connect"].ConnectionString );
if (con.State == ConnectionState.Closed)
{
con.Open();
}
return con;
}
#region execute command
public string Executecommand(SqlParameter []sqlparm,string sp)
{
string r_val = "";
try
{
SqlConnection con = new SqlConnection();
con = getcon();
SqlCommand cmd = new SqlCommand();
cmd.Connection = con;
cmd.CommandText = sp;
cmd.CommandType = CommandType.StoredProcedure;
foreach (SqlParameter loopvar_parm in sqlparm)
{
cmd.Parameters.Add(loopvar_parm);
}
cmd.Parameters.Add("#Var_Output", SqlDbType.VarChar, 20).Direction = ParameterDirection.Output;
cmd.ExecuteNonQuery();
r_val = (string)cmd.Parameters["#Var_Output"].Value;
con.Close();
}
catch { }
return r_val;
}
#endregion
#region Execute Dataset
public DataSet ExeccuteDataset(SqlParameter[] sqlParm, string sp)
{
DataSet ds = new DataSet();
try
{
SqlConnection con = new SqlConnection();
con = getConn();
SqlCommand cmd = new SqlCommand();
cmd.Connection = con;
cmd.CommandType = CommandType.StoredProcedure;
cmd.CommandText = sp;
foreach (SqlParameter LoopVar_param in sqlParm)
{
cmd.Parameters.Add(LoopVar_param);
}
cmd.ExecuteNonQuery();
SqlDataAdapter da = new SqlDataAdapter(cmd);
da.Fill(ds);
}
catch
{ }
return ds;
}
#endregion
#region grid
public void Bindgrid(DataSet ds,GridView g)
{
try
{
g.DataSource = ds.Tables[0];
g.DataBind();
}
catch { }
}
#endregion
#region Dropdownlist
public void Binddropdown(DropDownList dl,DataSet ds,string text,string value)
{
try
{
dl.DataSource = ds.Tables[0];
dl.DataTextField = text;
dl.DataValueField = value;
dl.DataBind();
}
catch
{}
}
#endregion
public conn()
{
//
// TODO: Add constructor logic here
//
}
}
}
dal
---------------
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using apm_conn;
using System.Data.SqlClient;
using apm_ent;
/// <summary>
/// Summary description for Class1
/// </summary>
namespace apm_dal
{
public class dal
{
conn ob_conn = new conn();
public dal()
{
//
// TODO: Add constructor logic here
//
}
public string insert(ent obj_ent)
{
SqlParameter[] sqlparm =
{
new SqlParameter ("#Var_Action",obj_ent.Var_Action),
new SqlParameter ("#Int_Id",obj_ent.Int_Id ),
new SqlParameter ("#Var_Product",obj_ent.Var_Product ),
new SqlParameter ("#Dc_Price",obj_ent.Var_Price ),
new SqlParameter ("#Int_Stat",obj_ent.Int_Stat ),
};
return ob_conn.Executecommand(sqlparm, "Proc_product");
}
public string ins(ent obj_ent)
{
SqlParameter[] parm =
{
new SqlParameter ("#Var_Action",obj_ent .Var_Action),
new SqlParameter ("#Int_Id",obj_ent .Int_Id),
};
return ob_conn.Executecommand(parm, "Proc_product");
}
}
}
bal
-------------
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using apm_ent;
using apm_dal;
/// <summary>
/// Summary description for bal
/// </summary>
namespace apm_Bal
{
public class bal
{
dal ob_dal = new dal();
string r_val = "";
public bal()
{
//
// TODO: Add constructor logic here
//
}
public string insert(ent obj_ent)
{
return ob_dal.insert(obj_ent);
}
}
}
Ent
------------
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
/// <summary>
/// Summary description for ent
/// </summary>
namespace apm_ent
{
public class ent
{
public ent()
{
//
// TODO: Add constructor logic here
//
}
#region Ent
public int Int_Id { get; set; }
public string Var_Action { get; set; }
public string Var_Product { get; set; }
public decimal Var_Price { get; set; }
public int Int_Stat { get; set; }
#endregion
}
}
page code
--------------
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using apm_conn;
using apm_ent;
using apm_Bal;
using apm_conn;
public partial class _Default : System.Web.UI.Page
{
conn obj_conn = new conn();
ent obj_ent = new ent();
bal obj_bal = new bal();
string r_val = "";
protected void Page_Load(object sender, EventArgs e)
{
}
protected void btnsub_Click(object sender, EventArgs e)
{
obj_ent.Var_Action = "INS";
obj_ent.Var_Product = txtproduct.Text;
obj_ent.Var_Price = Convert.ToDecimal (txtprice.Text);
r_val = obj_bal.insert(obj_ent);
if (r_val == "1")
{
Response.Write("<script>alert('Inserted Sucessfully')</script>");
}
}
}

Related

MAUI+ASP.NET DTOs

I have a project consisting of 2 parts:
ASP.NET API using Entity Framework
.NET MAUI Client App
I use DTOs for comunication from/to the API in order not to expose other properties of my entities. Thanks to this approach I was able to separate Entity data and data that are sent from the API.
At first I used these DTOs also in the MAUI UI. But after some time I started to notice that they contains UI-specific properties, attributes or methods that have no purpose for the API itself, so they are redundant in requests.
EXAMPLE:
1 - API will receive request from MAUI to get exercise based on it's name
2- ExerciseService returns: ExerciseEntity and ExerciseController use AutoMapper to Map ExerciseEntity -> ExerciseDto ommiting ExerciseId field (only admin can see this info in the DB) and returning it in the API response
3 - MAUI receives from the API ExerciseDto. But in the client side it also want to know if data from ExerciseDto are collapsed in the UI. So because of that I add IsCollapsed property into the ExerciseDto. But now this is a redundant property for the API, because I dont want to persist this information in the database.
QUESTIONS:
Should I map these DTOs to new objects on the client side ?
Or how to approach this problem ?
Is there an easier way how to achieve the separation ?
Because having another mapping layer will add extra complexity and a lot of duplicate properties between DTOs and those new client objects.
Normally if you use clean architecture approach your DTOs shoud contain no attributes and other specific data relevant just for some of your projects, to be freely usable by other projects in a form of dependency.
Then you'd have different approaches to consume DTOs in a xamarin/maui application, for example:
APPROACH 1.
Mapping (of course) into a class that is suitable for UI. Here you have some options, use manual mapping, write your own code that uses reflection or use some third party lib using same reflection. Personally using all of them, and when speaking of third party libs Mapster has shown very good to me for api and mobile clients.
APPROACH 2.
Subclass DTO. The basic idea is to deserialize dto into the derived class, then call Init(); if needed. All properties that you manually implemented as new with OnPropertyChanged will update bindings after being popupated by deserializer/mapper and you alse have a backup plan to call RaiseProperties(); for all of the props, even thoses who do not have OnPropertyChanged in place so they can update bindings if any.
Example:
our Api DTO
public class SomeDeviceDTO
{
public int Id { get; set; }
public int Port { get; set; }
public string Name { get; set; }
}
Our derived class for usage in mobile client:
public class SomeDevice : SomeDeviceDTO, IFromDto
{
// we want to be able to change this Name property in run-time and to
// reflect changes so we make it bindable (other props will remain without
// OnPropertyChanged BUT we can always update all bindings in code if needed
// using RaiseProperties();):
private string _name;
public new string Name
{
get { return _name; }
set
{
if (_name != value)
{
_name = value;
OnPropertyChanged();
}
}
}
// ADD any properties you need for UI
// ...
#region IFromDto
public void Init()
{
//put any code you'd want to exec after dto's been imported
// for example to fill any new prop with data derived from what you received
}
public void RaiseProperties()
{
var props = this.GetType().GetProperties();
foreach (var property in props)
{
if (property.CanRead)
{
OnPropertyChanged(property.Name);
}
}
}
public event PropertyChangedEventHandler PropertyChanged;
protected void OnPropertyChanged([CallerMemberName] string propertyName = "")
{
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
}
#endregion
}
public interface IFromDto : INotifyPropertyChanged
{
//
// Summary:
// Can initialize model after it's being loaded from dto
void Init();
//
// Summary:
// Notify all properties were updated
void RaiseProperties();
}
We can get it like: var device = JsonConvert.DeserializeObject<SomeDevice>(jsonOfSomeDeviceDTO);
We then can call Init(); if needed..
Feel free to edit this answer to add more approaches..

Wiring up any UI to my application

At present, I have very successfully architected my applications as follows:
Data model (Entity Framework 4.1)
Validation using Enterprise Library 5.0 Validation Application Block.
Object Context managed by a reusable class library.
So, the UI is pretty light on code but I know I'm not completely there yet.
If I wanted to have my projects set up so I could implement a Web Forms, MVC, WPF Desktop or Silverlight - even Windows Phone 7 - application, what additional steps might I need to take?
Here's some code, deliberately simplified, to illustrate my current state of play (I've omitted Code Contracts and the class libraries):
(Currently EF4 Model First and ASP .Net Web Forms)
Partial class for auto-generated entity
namespace MyNamespace.Database
{
using Microsoft.Practices.EnterpriseLibrary.Validation;
using Microsoft.Practices.EnterpriseLibrary.Validation.Validators;
[HasSelfValidation]
public partial class MyEntity : IMyEntity
{
[SelfValidation]
public void Validate(ValidationResults validationResults)
{
// Custom validation can go here, just add a new ValidationResult
// to validationResults if the rule fails.
if (validationResults != null)
{
validationResults.AddAllResults(
ValidationFactory
.CreateValidator<IMyEntity>()
.Validate(this));
}
}
}
}
Validation
namespace MyNamespace.Database
{
using System.ComponentModel.DataAnnotations;
using System.Diagnostics.Contracts;
using Microsoft.Practices.EnterpriseLibrary.Validation;
using Microsoft.Practices.EnterpriseLibrary.Validation.Validators;
[ContractClass(typeof(MyEntityContract))]
public interface IMyEntity
{
int Id
{
get;
set;
}
[Required]
[NotNullValidator]
[StringLengthValidator(0, RangeBoundaryType.Ignore, 50,
RangeBoundaryType.Inclusive,
MessageTemplate = "MyEntity Name must be 50 characters or less.")]
string Name
{
get;
set;
}
void Validate(ValidationResults validationResults);
}
}
Facade for data access
namespace MyNamespace.Facade
{
using System.Collections.Generic;
using System.Linq;
using Common.ObjectContextManagement;
using Database;
public sealed class MyEntityFacade : FacadeBase<MyEntities, MyEntity>
{
public IEnumerable<MyEntity> GetAll()
{
return this.ObjectContext.MyEntitys
.Distinct()
.ToList();
}
}
}
Web App UI
using (new UnitOfWorkScope(false))
{
this.MyEntityList.DataSource = new MyEntityFacade().GetAll();
this.MyEntityList.DataBind();
}
// Or...
using (var scope = new UnitOfWorkScope(false))
{
var myEntityFacade = new MyEntityFacade();
var myEntity = new MyEntity();
PopulateEntity(myEntity);
// Validation errors are automatically presented
// to the user from the Validate method
if (Validate(myEntity))
{
try
{
myEntityFacade.Add(myEntity);
scope.SaveAllChanges();
}
catch (Exception exception)
{
Logging.Write("Error", LoggingLevel.Error, exception.Message);
}
}
}
How close am I?
The easiest way to expose your middle/backend so that a variety of clients can hook up is to wrap it all in one or more web services. In your example you can consider either exposing MyEntityFacade as a WCF service, or you can build an entirely new tier that passes back and forth between your client(s) and the facade.
If you stick to POCO objects and SOAP, you can probably factor in connectivity from java, javascript, python, etc. in addition to your listed clients.

Managing NHibernate sessions for a multi-tenant ASP.NET application

I have an existing multi-tenant ASP.NET application where all users authenticate against a single SQL Server database. This database also contains several other settings type data that is used within the application. Each client after authentication, utilizes their own SQL Server database for data storage, for isolation purposes. Essentially all of the client database are identical and reside on the same server, but reside on one or more servers as well.
The application is currently written in asp.net 2.5 framework and utilizes the Microsoft Practices Enterprise Library for DAL, and we are looking to migrate to 4.0 and implement NHibernate to replace the MPEL.
I have implemented a solution already using NHibernate and the 4.0 framework, so I am familiar with the concepts. I found the resources for my current session manager here as a matter of fact. But that application only had a single database, so not much too it. The implementation is essentially what you see here:
http://www.lostechies.com/blogs/nelson_montalvo/archive/2007/03/30/simple-nhibernate-example-part-4-session-management.aspx
The other solutions that I have seen suggest multiple config entries and/or files to manage this, but that is not desirable, since we may add new clients frequently and all of the connection information is already maintained in the authentication database.
Does anyone have any suggestions on how I might be able to pass in the client's connection string to a session manager?
The following is my current session manager class, which is based on the article mentioned above.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.Remoting.Messaging;
using System.Web;
using NHibernate;
using NHibernate.Cfg;
using NHibernate.Cache;
using singlepoint.timeclock.domain;
namespace singlepoint.timeclock.repositories
{
/// <summary>
/// Handles creation and management of sessions and transactions. It is a singleton because
/// building the initial session factory is very expensive. Inspiration for this class came
/// from Chapter 8 of Hibernate in Action by Bauer and King. Although it is a sealed singleton
/// you can use TypeMock (http://www.typemock.com) for more flexible testing.
/// </summary>
public sealed class nHibernateSessionManager
{
private ISessionFactory idadSessionFactory;
private ISessionFactory clientSessionFactory;
private string _client;
#region Thread-safe, lazy Singleton
// lazy initialisation, therefore initialised to null
private static nHibernateSessionManager instance = null;
/// <summary>
/// This is a thread-safe, lazy singleton. See http://www.yoda.arachsys.com/csharp/singleton.html
/// for more details about its implementation.
/// </summary>
public static nHibernateSessionManager Instance
{
get { return GetInstance(); }
}
public static nHibernateSessionManager GetInstance()
{
// lazy init.
if (instance == null)
instance = new nHibernateSessionManager();
return instance;
} // GetInstance
/// <summary>
/// Initializes the NHibernate session factory upon instantiation.
/// </summary>
private nHibernateSessionManager()
{
InitSessionFactory();
}
/// <summary>
/// Initializes the NHibernate session factory upon instantiation.
/// </summary>
private nHibernateSessionManager(string client)
{
InitSessionFactory();
InitClientSessionFactory(client);
}
/// <summary>
/// Assists with ensuring thread-safe, lazy singleton
/// </summary>
private class Nested
{
static Nested()
{
}
internal static readonly nHibernateSessionManager nHibernatenHibernateSessionManager = new nHibernateSessionManager();
}
#endregion
private void InitSessionFactory()
{
var configuration = new Configuration();
configuration.Configure(System.Configuration.ConfigurationManager.AppSettings["IDAD_HBM"]);
configuration.AddAssembly(typeof(enterprise).Assembly);
idadSessionFactory = configuration.BuildSessionFactory();
}
private void InitClientSessionFactory(string client)
{
var configuration = new Configuration();
configuration.Configure(System.Configuration.ConfigurationManager.AppSettings["Client_IDAD_HBM"]);
configuration.SetProperty("connection.connection_string", client);
configuration.AddAssembly(typeof(enterprise).Assembly);
clientSessionFactory = configuration.BuildSessionFactory();
}
/// <summary>
/// Allows you to register an interceptor on a new session. This may not be called if there is already
/// an open session attached to the HttpContext. If you have an interceptor to be used, modify
/// the HttpModule to call this before calling BeginTransaction().
/// </summary>
public void RegisterInterceptor(IInterceptor interceptor)
{
ISession session = ThreadSession;
if (session != null && session.IsOpen)
{
throw new CacheException("You cannot register an interceptor once a session has already been opened");
}
GetSession(interceptor);
}
public ISession GetSession()
{
return GetSession(null);
}
/// <summary>
/// Gets a session with or without an interceptor. This method is not called directly; instead,
/// it gets invoked from other public methods.
/// </summary>
private ISession GetSession(IInterceptor interceptor)
{
ISession session = ThreadSession;
if (session == null)
{
if (interceptor != null)
{
session = idadSessionFactory.OpenSession(interceptor);
}
else
{
session = idadSessionFactory.OpenSession();
}
ThreadSession = session;
}
return session;
}
public void CloseSession()
{
ISession session = ThreadSession;
ThreadSession = null;
if (session != null && session.IsOpen)
{
session.Close();
}
}
public void BeginTransaction()
{
ITransaction transaction = ThreadTransaction;
if (transaction == null)
{
transaction = GetSession().BeginTransaction();
ThreadTransaction = transaction;
}
}
public void CommitTransaction()
{
ITransaction transaction = ThreadTransaction;
try
{
if (transaction != null && !transaction.WasCommitted && !transaction.WasRolledBack)
{
transaction.Commit();
ThreadTransaction = null;
}
}
catch (HibernateException ex)
{
RollbackTransaction();
throw ex;
}
}
public void RollbackTransaction()
{
ITransaction transaction = ThreadTransaction;
try
{
ThreadTransaction = null;
if (transaction != null && !transaction.WasCommitted && !transaction.WasRolledBack)
{
transaction.Rollback();
}
}
catch (HibernateException ex)
{
throw ex;
}
finally
{
CloseSession();
}
}
/// <summary>
/// If within a web context, this uses <see cref="HttpContext" /> instead of the WinForms
/// specific <see cref="CallContext" />. Discussion concerning this found at
/// http://forum.springframework.net/showthread.php?t=572.
/// </summary>
private ITransaction ThreadTransaction
{
get
{
if (IsInWebContext())
{
return (ITransaction)HttpContext.Current.Items[TRANSACTION_KEY];
}
else
{
return (ITransaction)CallContext.GetData(TRANSACTION_KEY);
}
}
set
{
if (IsInWebContext())
{
HttpContext.Current.Items[TRANSACTION_KEY] = value;
}
else
{
CallContext.SetData(TRANSACTION_KEY, value);
}
}
}
/// <summary>
/// If within a web context, this uses <see cref="HttpContext" /> instead of the WinForms
/// specific <see cref="CallContext" />. Discussion concerning this found at
/// http://forum.springframework.net/showthread.php?t=572.
/// </summary>
private ISession ThreadSession
{
get
{
if (IsInWebContext())
{
return (ISession)HttpContext.Current.Items[SESSION_KEY];
}
else
{
return (ISession)CallContext.GetData(SESSION_KEY);
}
}
set
{
if (IsInWebContext())
{
HttpContext.Current.Items[SESSION_KEY] = value;
}
else
{
CallContext.SetData(SESSION_KEY, value);
}
}
}
private static bool IsInWebContext()
{
return HttpContext.Current != null;
}
private const string TRANSACTION_KEY = "CONTEXT_TRANSACTION";
private const string SESSION_KEY = "CONTEXT_SESSION";
[Obsolete("only until we can fix the session issue globally")]
internal ISession OpenSession()
{
return idadSessionFactory.OpenSession();
}
}
}
This is being called from a repository class like so:
public string getByName(string name)
{
return getByName(nHibernateSessionManager.Instance.GetSession(), name);
}
What I would really like to be able to do is the following:
public string getByName(string name, string clientConnectionString)
{
return getByName(nHibernateSessionManager.Instance.GetSession(clientConnectionString), name);
}
But I am having trouble modifying my existing session manager to accomodate this.
You appear to be asking to swap a connection for a given session. Or rather that is certainly what the code you have written is asking - "return a session identified by the name parameter, and it should also now use the connection string provided by this method."
That is not possible. NHibernate builds a session (and actually really a session factory) per connection and once built the factory and session are immutable. You cannot change connections for an existing session.
I got the impression that your application involves mostly in initial connection string that is the moving target, but after that your "real" session is on a single database. If that is the case, NHibernate can easily do this. If that is not the case, well, some things NHibernate is just not that well suited for. Maybe understanding a little more about the basis NHibernate operates on is helpful either way?
One of my genuine criticisms of NHibernate is that you have a somewhat arcane use of terminology and the well known unhelpful nature of it's exception messages. These coupled with the fact that what it is doing is in reality mechanically complicated tends to really obscure that there is a relatively simple and technically sound underlying model.
In this case, if you think about it this business of an immutable session makes a lot of sense. NHibernate connects to a database, but it also maintains objects in the session so they can be persisted back to that database at a later time. NHibernate does not support changing connections per session because there may already be other objects in the session and if you change connections their persistence is no longer assured.
Now, what you can do is create a factory/session per database for multiple databases and access them in one application, but objects still belong to their own session. You can even move objects to a new session with a different connection. In this case you have what would logically be a "replication" scenario. NHibernate supports this but you have to do most of the work. This also makes sense - they really cannot give you that as stable out of the box functionality, you have to manage a process like that on your own.
You can also build code to do exactly what you are asking. But think about what that is. Make a session, not per database, but only for this specific instance of this specific repository. I am thinking that is most likely not really what you want. But that is exactly what the semantics of your request are saying to do. Your existing class, On the other hand, was built on different semantics which are more typically what people want - "Build a session for this particular connection definition, i.e this database."
A real need to inject a connection string at the repository level implies that now not only is the database a moving target, but at the actual table level the target also moves. If that is the case, NHibernate is possibly not a good option. If that is not the case, you may be trying to mix programming paradigms. NHiberate imposes a few what I would call "assumptions" rather than any sort of real "limitations" and in return you don't have to write a bunch of code that would allow you a finer grain of control because often you really don't need that additional control.
Sorry if this is no longer a direct answer to your question, hopefully it is helpful somehow.
Original Answer:
Sure, since the connection info is in the authentication database this is easy.
1) Configure NHibernate in the "usual" fashion and point the config at the authentication database. Get the db connection for the user, and then close that session and session factory. You are done with that one now.
2) Create a new session etc this time in code instead of a config file.
class MyNewSession
{
private ISession _session;
private ISessionFactory _factory;
public void InitializeSession()
{
NHibernate.Cfg.Configuration config = new NHibernate.Cfg.Configuration();
config.Properties.Clear();
IDictionary props = new Hashtable();
// Configure properties as needed, this is pretty minimal standard config here.
// Can read in properties from your own xml file or whatever.
// Just shown hardcoded here.
props["proxyfactory.factory_class"] = "NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle";
props["connection.provider"] = "NHibernate.Connection.DriverConnectionProvider";
props["dialect"] = "NHibernate.Dialect.MsSql2000Dialect";
props["connection.driver_class"] = "NHibernate.Driver.SqlClientDriver";
props["connection.connection_string"] = "<YOUR CONNECTION STRING HERE>";
props["connection.isolation"] = "ReadCommitted";
foreach (DictionaryEntry de in props)
{
config.Properties.Add(de.Key.ToString(), de.Value.ToString());
}
// Everything from here on out is the standard NHibernate calls
// you already use.
// Load mappings etc, etc
// . . .
_factory = config.BuildSessionFactory();
_session = _factory.OpenSession();
}
}
I know this is old but if you have not found a solution I hope this will help,
I created a solution that uses multisessionfactory using unhaddins (I made alterations to suit my needs).
Basically the multisession factory creates session factories for each database and stores in Application object.
Depending on the client the call to getfactory("name of factory from factory config file") returns correct database to query on.
You will have to alter your management module to support this and all of your repositories to support the change in management. This may be impractical at first but you have to alter them anyway. Your calls from your repository can be something like this:
public string getByName(string name)
{
return getByName(nHibernateSessionManager.SessionFactoryManager.GetFactory(Session["session variable that holds client session factory name that was set on login"]).GetCurrentSession(), name);
}
or (creating a method in the sessionmanager to return session of a given factory) your code could be like this
public string getByName(string name)
{
return getByName(nHibernateSessionManager.GetSession(Session["session variable that holds client session factory name that was set on login"]), name);
}

Separating UI from Data Access in ascx user control

What is the "best practice" for designing ascx user controls regarding separating the UI from the Data Access? Should my user control use 3 tier archetecture as in my projects or can I do the data acess from within the user control?
You should never access the database from a user control. You should create a class for accessing the database, and everything within your application should use that class. Basically, the methods in the class would be wrappers around your stored procedure calls, but all that the application (and therefore user controls) sees is a method with the needed parameters. No knowledge of the database from the application's point of view. That allows you to make changes to the database without changing your application.
This link might help you:
http://www.simple-talk.com/dotnet/.net-framework/.net-application-architecture-the-data-access-layer/
Now matter how simple or complex a project, at the very least, all should be separated into a Presentation Layer, Business Layer, and Data Layer. At any given time any one of the three could change without affecting the others.
A user control is part of the presentation layer, it should supply data and user actions to the business layer which in turn interprets the data and those actions to make decisions. If necessary the business layer would call the Data Layer. The Data Layer in turn would handle all communication with the database/source files.
It's not that hard to separate the three and keep them separate.
I would definitely suggest to access data from some kind of business layer. UI never should access databases directly.
What if your access rules changed?
What if your storage changed?
Can you ensure, that every UI control is able to enforce business rules?
etc.
This is what I have in my project.
1.) Application.Infrastructure
Base classes for all businessobjects, busines object collection, data-access classes and my custom attributes and utilities as extension methods, Generic validation framework. This determines overall behavior organization of my final .net application.
2.) Application.DataModel
Typed Dataset for the Database.
TableAdapters extended to incorporate Transactions and other features I may need.
3.) Application.DataAccess
Data access classes.
Actual place where Database actions are queried using underlying Typed Dataset.
4.) Application.DomainObjects
Business objects and Business object collections.
Enums.
5.) Application.BusinessLayer
Provides manager classes accessible from Presentation layer.
HttpHandlers.
My own Page base class.
More things go here..
6.) Application.WebClient or Application.WindowsClient
My presentation layer
Takes references from Application.BusinessLayer and Application.BusinessObjects.
Application.BusinessObjects are used across the application and they travel across all layers whenever neeeded [except Application.DataModel and Application.Infrastructure]
All my queries are defined only Application.DataModel.
Application.DataAccess returns or takes Business objects as part of any data-access operation. Business objects are created with the help of reflection attributes. Each business object is marked with an attribute mapping to target table in database and properties within the business object are marked with attributes mapping to target coloumn in respective data-base table.
My validation framework lets me validate each field with the help of designated ValidationAttribute.
My framrwork heavily uses Attributes to automate most of the tedious tasks like mapping and validation. I can also new feature as new aspect in the framework.
A sample business object would look like this in my application.
User.cs
[TableMapping("Users")]
public class User : EntityBase
{
#region Constructor(s)
public AppUser()
{
BookCollection = new BookCollection();
}
#endregion
#region Properties
#region Default Properties - Direct Field Mapping using DataFieldMappingAttribute
private System.Int32 _UserId;
private System.String _FirstName;
private System.String _LastName;
private System.String _UserName;
private System.Boolean _IsActive;
[DataFieldMapping("UserID")]
[DataObjectFieldAttribute(true, true, false)]
[NotNullOrEmpty(Message = "UserID From Users Table Is Required.")]
public override int Id
{
get
{
return _UserId;
}
set
{
_UserId = value;
}
}
[DataFieldMapping("UserName")]
[Searchable]
[NotNullOrEmpty(Message = "Username Is Required.")]
public string UserName
{
get
{
return _UserName;
}
set
{
_UserName = value;
}
}
[DataFieldMapping("FirstName")]
[Searchable]
public string FirstName
{
get
{
return _FirstName;
}
set
{
_FirstName = value;
}
}
[DataFieldMapping("LastName")]
[Searchable]
public string LastName
{
get
{
return _LastName;
}
set
{
_LastName = value;
}
}
[DataFieldMapping("IsActive")]
public bool IsActive
{
get
{
return _IsActive;
}
set
{
_IsActive = value;
}
}
#region One-To-Many Mappings
public BookCollection Books { get; set; }
#endregion
#region Derived Properties
public string FullName { get { return this.FirstName + " " + this.LastName; } }
#endregion
#endregion
public override bool Validate()
{
bool baseValid = base.Validate();
bool localValid = Books.Validate();
return baseValid && localValid;
}
}
BookCollection.cs
/// <summary>
/// The BookCollection class is designed to work with lists of instances of Book.
/// </summary>
public class BookCollection : EntityCollectionBase<Book>
{
/// <summary>
/// Initializes a new instance of the BookCollection class.
/// </summary>
public BookCollection()
{
}
/// <summary>
/// Initializes a new instance of the BookCollection class.
/// </summary>
public BookCollection (IList<Book> initialList)
: base(initialList)
{
}
}
You need at a minimum, a 2 layer solution: data, then everything else. For a more complex project, you need to take that everything else and abstract it out into presentation, logic, data. Data can also be separated into data access and data model layers.

What to return from the DAL to BLL

I currently have an application which consists of:
User Interface (web page)
BLL (Manager & Domain Objects)
DAL (DataAccess class for each of my Domain Objects).
I use the following in the UI to search for a domain object.
protect sub Button1_Click()
{
IBook book = BookManager.GetBook(txtID.Text);
}
Here is my BLL
public class BookManager
{
public static IBook GetBook(string bookId)
{
return BookDB.GetBook(bookId);
}
}
public class Book : IBook
{
private int? _id
private string _name;
private string _genre;
public string Name
{
get { return _name; }
private set
{
if (string.IsNullOrEmpty(value))
throw new Exception("Invalid Name");
_name = value;
}
}
public string Genre
{
get { return _serial; }
private set
{
if (string.IsNullOrEmpty(value))
throw new Exception("Invalid Genre");
_genre = value;
}
}
// Other IBook Implementations
}
And finally here is my DAL
public class BookDB
{
public static IBook GetBook(int id)
{
// Get Book from database using sproc (not allowed to use any ORM)
// ?? Create IBook Item?
// return IBook
}
How would one create a IBook Object and return it to the Manager?
I'm thinking of returning a DataTable from BookDB to BookManager and having it create the Book Object and return it, but that doesn't seem right.
Is there another way to do this?
Edit:
I decided to seperate each layer into a project and ran into a circular dependency problem in the DAL layer when trying to add a reference to the BLL.
I can't access the Book Class or Interface or anything in BLL from DAL.
Should i just use ado.net objects here and have my manager create the actual object from the ado.net object?
Here's how its layed out
BLL.Managers - BookManager
BLL.Interfaces IBook
BLL.Domain - Book
DAL - BookDB.
Thanks!
You could create dummy Book objects that contain only data. Get, set properties and member values. This book, has 1 property for each field in the database, but doesn't validate anything.
You fill the object from the db, then send it to the BLL.
When you want to save the object, you also send it to the BLL.
Your classes in the BLL could wrap aroud those objects, if that makes sense. This way, it is easy to just send it back to the DAL.
Dummy Book:
public class DummyBook:IBook
{
private nullable<int> _id;
private string _name;
private string _genre;
public string Id
{
get {return _id;}
set {_id = value;}
}
public string Name
{
get {return _name;}
set {_name = value;}
}
public string Genre
{
get {return _genre;}
set {_genre= value;}
}
}
DAL Book:
public class DALBook
{
public static IBook:GetBook(int id)
{
DataTable dt;
DummyBook db = new DummyBook();
// Code to get datatable from database
// ...
//
db.Id = (int)dt.Rows[0]["id"];
db.Name = (string)dt.Rows[0]["name"];
db.Genre = (string)dt.Rows[0]["genre"];
return db;
}
public static void SaveBook(IBook book)
{
// Code to save the book in the database
// you can use the properties from the dummy book
// to send parameters to your stored proc.
}
}
BLL Book:
public class Book : IBook
{
private DummyBook _book;
public Book(int id)
{
_book = DALBook.GetBook(id);
}
public string Name
{
get {return _book.Name;}
set
{
if (string.IsNullOrEmpty(value))
{
throw new Exception("Invalid Name");
}
_book.Name = value;
}
}
// Code for other Properties ...
public void Save()
{
// Add validation if required
DALBook.Save(_book);
}
}
Edit1: The dummy classes should go in their own project(Model, just as stated in the comments is fine). The references would work as follow:
The DAL References the Model Project.
The BLL References the Model and the DAL.
The UI References the BLL.
BookDB should return the IBook instance. I like the repository pattern, which is all about mapping from the db to the domain.
The repository implementation returns instances of the domain objects. This shields the rest of the code from the particular persistence implementation, which can be affected by the technology (database type, web service, [insert something else]) and the format used to save the data.
I would probably use ExecuteReader to create an object in code from the database. The reason for this is that the datatable has more overhead than a reader, because it has more functionality (and was probably created by a reader). Since you aren't doing updates/deletes using the datatable, you don't need the overhead.
That being said, I would make a static helper method in the BookManager class.
internal static IBook BookFromReader(IDataReader reader)
{
Book B = new Book();
B.Prop = reader.GetString(0);
B.Rinse = reader.Repeat();
return B;
}
The reason for this is because the reason you have an interface is because you might want to change the implementation. You may eventuallu have INovel : IBook, IReference : IBook etc and then you'll want to have an abstract factory implementation in your data layer.
public static IBook GetBook(int id)
{
// SqlCommand Command = new Command("SQL or sproc", ValidConnection);
using(IDataReader DR = Command.ExecuteReader(id))
{
// checking omitted
switch(DR.GetInt32(1))
{
case 0:
return BookManager.BookFromReader(DR);
case 1:
return BookManager.NovelFromReader(DR);
etc
}
}
}
Another benefit of the DAL here is that you can cache lookups. You can have a Dictionary that holds books you've looked up, to reduce extra db calls on objects you've already returned. When an update takes place, you remove the cached entity... That's another post though.
If you're using multiple assemblies, interfaces and helper methods will need to reside in a neutral (non-dependent) assembly. Right now in the blog-o-sphere, there is movement towards less assemblies, which means less dependencies, etc.
Here is a link from a blog I read on this topic:
http://codebetter.com/blogs/patricksmacchia/archive/2008/12/08/advices-on-partitioning-code-through-net-assemblies.aspx
Ultimately, I think the answer is that the data layer returns an instance of your interface to the business layer.
Good luck :-)
In my opinion you should never let DAL access BLL. That is an unnecessarily dependency.
Putting the Book class into a new project (perhaps named DomainModel) will fix the circular reference. You could do something like this:
Project BLL reference DAL and DomainModel
Project DAL reference DomainModel
Project UI reference BLL and DomainModel
Project DomainModel reference nothing
The DataTable you want to return is database related, and for BLL, it shouldn't care about what database you are using and what the schema is.
You may use a DB-Object Mapper to map the dbtable to an object in DAL.
If you don't want to return a DataTable, you can pass in an IBook implementation from BookManager for the DAL to populate.
To follow the intended model. the Data Access Layer (DAL) is responsible for retrieving and sending data from and to the data source.
The DAL must not care about any of the business entities your BLL is using as its only job is to retrieve data and return it in a neutral object. It must be neutral for generic reuability, otherwise you might as well not separate the layers as you are defiting its purpose.
Your Business Logic Layer (BLL) must not care how the DAL achieves retrieveing or writing data.
To communicate between the BLL and the DAL you must use neutral objects.
Your BLL passes an object's properties as individual paramters to the methods in the DAL.
the parameters in the DAL are neutral using strings, int, bool, any other .NET objects which are neither specific to a version of the database you are communicating with nor are specific types only existing in your BLL.
The DAL will retrieve the data from where ever by what ever means and return a neutral data object to the caller. This for example could be a DataSet or DataTable or any other object NOT specific to a database type/version your are using. Hence DataSet and DataTable are objects within the System.Data namespace and not the System.Data.SQL,etc... namespace.
In essence:
- BLL passes neutral types to the DAL (e.g.: string, int, bool, long,float, etc..)
- DAL is responsible for converting those types to database specifci types if required before passing them on to the data source
DAL returns neutral data types to the BLL (e.g.: DataSet, DataTable,etc..)
- BLL is responsible for using the content of those neutral data types to create, populate and return specifci Business Entities
Your BLL must reference your DAL. that's it.
You can off course completly ignore this model and hack about as many suggested previously using IBOOK,etc... but than your are not using the intended model and might as well throw it all into a single assembly as you won't be able to maintain it independantly anyway.

Resources