ntier.htm

LLBLGen 1.21 Sourcecode

			with .NET Remoting, Webservices or the CLR.</li>
		<li><b>GUI support tier, Business logic tier and Business logic support tier</b>. These tiers are implemented mostly in
			stateless COM+ or MTS objects, using a variety of languages: VC++, Visual Basic, Delphi, even VBScript. The shared
			technology used is again COM, to interface with eachother or the COM+/MTS framework. In the .NET world, COM+ is
			still used to provide transactional services on the binary object level. Besides that, .NET takes over the interfacing
			between objects: Webservices, .NET Remoting or the CLR itself are used to make interfacing between managed objects
			possible.</li>
		<li><b>Data-access tier</b>. This tier is mostly implemented in 2 parts: one is build entirely using stored procedures
			stored in the RDBMS, the other part is a thin layer build with COM using Visual Basic, VC++, Delphi or even VBScript,
			using the stored procedures to perform actions on the data in the tables stored inside the RDBMS. Other parts
			of the Data-access tier can be XML read/write services or simple file reader/writers, even serial port readers
			are sometimes part of the data-access tier. In the .NET world the stored procedures are still there, the layer
			using them is build with .NET classes and languages to run inside the CLR.</li>
	</ul>
	Datablocks are passed between layers using disconnected ADO recordsets or in the .NET world using ADO.NET objects like
	Dataset or Datatable. The interfaces provided by the tiers are in the 'old fashioned' Windows DNA world provided by DCOM
	or COM, in .NET the developer has the ability to use Webservices to provide an interface of a tier, .NET Remoting (which
	is similar to Webservices) or when the tiers run on the same machine, using application domains and references to 
	assemblies, the CLR does manage the interfacing internally as if the application is one single assembly. 
	COM+ is necessary, even in .NET, when transactional services are needed at the component level. These transactions can 
	cross tier-boundaries. 
	
	<h4>Stateless development</h4>
	A remark on stateless development is in order, because a lot of developers misunderstand what 'state' really means
	in the n-tier context. By convention, all n-tier applications should be 'stateless'. This means that the total application
	is not in some kind of 'state' by holding information in memory, or better: the separate tiers shouldn't be in a certain
	'state' where they hold information in memory. The 'state' of the application is held by the database(s) used. This model
	is completely the opposite of the stateful way how so called 'fat'-clients used to work: the user worked with the
	complete application on his machine, and the application's state was held in memory. 
</p>
<p>
	The reason for a stateless approach is quite simple: multi-user. In a fat-client, single user system, the application state
	was the same as the user's state, and thus it was a great performance gain to keep that user-state in memory instead of
	the database. For a set of black-boxes stacked on top of each other, serving more than one user, the application state
	is not the same as the user's state, in fact, for every user, the application can act completely different. In these
	circumstances, the n-tier application world, a stateless approach is more convenient since the logic can assume correctly
	what the current state of the application is (which is stored in the database) and can use other system parts, like COM+
	and MTS or even webservices, without having to negotiate a current 'state'. Also the reuse of system resources is very 
	flexible in a stateless environment: as soon as a given object is done using another object, it is destroyed (normal
	objects) or returned to a pool (for example connection objects), and not hold in some global store. When thousands of
	users are using the system, it still will perform well, because it doesn't keep thousands of objects in a global object
	store but shares a smaller group of objects among the ones who need them.
</p>
<p>
	How does this work? Very simple. Every piece of code in the n-tier application has 'stateless' written all over it. 
	So every piece of code in the application isn't stored in some global object storage, but is created when needed and
	destroyed and disposed when it's not needed anymore. Typically the usage of some logic in a certain tier goes like this:
	<ul>
		<li>Create an object instance of the class which will perform the action for us</li>
		<li>Set properties of the object so the action will go as planned</li>
		<li>Call the method to perform the action we want</li>
		<li>Receive returnvalue(s) from the method just called</li>
		<li>Destroy the object</li>
	</ul>
	This way, you will not have to keep track of running objects which could influence your logic, you simply do as
	you're alone in the system: call the methods of the object just created. Stateless code is very readable and simple
	to maintain, because of this. 
</p>
<p>
	Because most n-tier applications work with databases, the application requires data, works with data and users 
	modify/supply data which should be stored. This implies that the application stores every datachange back into the
	database a.s.a.p., which is also a result of the stateless programming method, since the object holding some data
	is destroyed as soon as the methods which should have been called, have finished. 
</p>
<p>
	<b class="SmallHdr">User state</b><br>
	User state is a confusing term, because in a way, it <i>is</i> a form of stateful programming. User state is the
	state of the application for a typical user, but only in such a way that the user <i>thinks</i> the application
	is in his state, which means most of the time, just GUI related data is kept in a stateful global store, typical
	in session related objects, which are common in the ASP and ASP.NET world. ASP developers know as a rule of thumb
	not to keep large objects in the 'session' object, like recordsets or open database connections. The reason for this
	is that the application suddenly becomes stateful even if the developer didn't intend this. In the .NET world, this
	hasn't changed. User state, for example the information a user has provided on page one and two on a four page wizard,
	is light and influences only the GUI tiers. Data meant for other tiers shouldn't be kept in the user state but should
	be stored in the database. As a rule of thumb use this: "when tier N, N being not the GUI layer, is changed into a 
	stateless webservice, placed on a webserver on the internet, thus not in your local secure network, will the 
	application still work as planned or do you have to change a lot in the application to keep it together?"
	When you have to change a lot, your application isn't stateless, when you don't have to change a lot, your application
	is pretty stateless and you're well on track!
</p>
<p>
	Now, let's see where LLBLGen comes into the picture with this n-tier application stuff.
</p>
<h4>N-tier development and LLBLGen</h4>
<p>
	LLBLGen is short for <b>L</b>owest <b>L</b>evel <b>B</b>usiness logic <b>L</b>ayer <b>GEN</b>erator, meaning 
	by 'lowest level business logic layer' the data-tier of the stacks above. 
	(I tend to call it the lowest level business logic layer, that's why the tools name is LLBLGen and not DATGen or
	DALGen). LLBLGen therefor generates the complete data-access tier, based on the database given. This means that
	in a 3-tier application, one-third (when all tiers are of the  same size) of the application is generated. 
	Of course a full blown data-tier requires extra code a generator normally can't produce by simply interpreting the
	database structure. However, the fast majority of the code needed for a typical data-access tier is generated
	by LLBLGen, which is a great win in both time and development-fun, since data-access tier code is pretty repetitive
	and boring to produce, especially for a large database with a lot of tables and views.
</p>
<p>
	LLBLGen follows the typical aspects of n-tier development as described above. This means that the data-access tier
	generated by LLBLGen is stateless and is ment to be used in a stateless environment. This means that no DataReader
	objects are returned nor DataSets with corresponding DataAdapters, but solely DataTables and field data. The 
	developer using the data-access tier generated should use the classes in a stateless way: create an instance of a
	generated class when needed, set properties, call a method, read the result values and destroy the object. LLBLGen
	is also able to generate extra code to make it possible to run the object instances of the generated classes in
	COM+ environments, thus cross-tier transactions, and provides a solid mechanism to the data-access tier consuming
	layer to perform ADO.NET based transactions, without compromising the database-unawareness of that layer.
</p>
<div align="right" class="SmallFontTOC">
	<hr size="1" width="60%" align="right">
	LLBLGen v1.2 documentation. &copy; 2002 <a href="http://www.sd.nl/" target="_blank">Solutions Design</a>
</div>
<br><br><br>
</BODY>
</HTML>