codestructure.htm

LLBLGen 1.21 Sourcecode

			<td class="TDSmallerFont">Insert</td>
			<td class="TDSmallerFont">[SP prefix][TableName]_Insert</td>
			<td class="TDSmallerFont">pr_Foo_Insert</td>
		</tr>
		<tr>
			<td class="TDSmallerFont">Delete</td>
			<td class="TDSmallerFont">[SP prefix][TableName]_Delete</td>
			<td class="TDSmallerFont">pr_Foo_Delete</td>
		</tr>
		<tr>
			<td class="TDSmallerFont">DeleteAllWPrimaryKeyFieldLogic</td>
			<td class="TDSmallerFont">[SP prefix][TableName]_DeleteAllW[Field_Name]Logic</td>
			<td class="TDSmallerFont">pr_Foo_DeleteAllWMy_FieldLogic</td>
		</tr>
		<tr>
			<td class="TDSmallerFont">Update</td>
			<td class="TDSmallerFont">[SP prefix][TableName]_Update</td>
			<td class="TDSmallerFont">pr_Foo_Update</td>
		</tr>
		<tr>
			<td class="TDSmallerFont">UpdateAllWForeignKeyFieldLogic</td>
			<td class="TDSmallerFont">[SP prefix][TableName]_UpdateAllW[Field_Name]Logic</td>
			<td class="TDSmallerFont">pr_Foo_UpdateAllWMy_FieldLogic</td>
		</tr>
		<tr>
			<td class="TDSmallerFont">SelectOne</td>
			<td class="TDSmallerFont">[SP prefix][TableName]_SelectOne</td>
			<td class="TDSmallerFont">pr_Foo_SelectOne</td>
		</tr>
		<tr>
			<td class="TDSmallerFont">SelectAll</td>
			<td class="TDSmallerFont">[SP prefix][TableName]_SelectAll</td>
			<td class="TDSmallerFont">pr_Foo_SelectAll</td>
		</tr>
		<tr>
			<td class="TDSmallerFont">SelectAllWForeignKeyLogic</td>
			<td class="TDSmallerFont">[SP prefix][TableName]_SelectAllW[Field_Name]Logic</td>
			<td class="TDSmallerFont">pr_Foo_SelectAllWMy_FieldLogic</td>
		</tr>
	</table>
	<br clear="all">
	You shouldn't use spaces in table names, and you should avoid spaces in fieldnames. LLBLGen will
	generate code that will handle names with spaces correctly, however it's more cumbersome to
	write T-SQL code using tablenames and fieldnames with spaces. 
</p>
<p>
	<h5>.NET code</h5>
	<b>VB.NET or C#?</b><br>
	Allthough .NET gives the developer the oppertunity to mix languages, it's often nice to have all code in your
	solution in one language. The generated code by LLBLGen is ment to be extended, so when this code is in another
	language than the one the rest of the project is written in, this can be a problem. LLBLGen supports C# and VB.NET
	as output languages. In both cases, LLBLGen will emit code that should work the same, thus will have the same
	interface and behaviour.
	<br><br>
	<b>.NET base class.</b><br>
	LLBLGen generated code uses an abstract base class which is used to derive all the .NET classes from. 
	This class contains the connection object needed for each .NET class and a property
	which will reflect the ErrorCode T-SQL variable, if the user selected generation of that code. Also this abstract base
	class is created with extensibility in mind, so developers can add code which is common for all .NET classes to
	this base class without any hassle with the other generated code. This abstract base class also contains, when selected, 
	COM+ attributes so all table .NET classes will inherit these COM+ services settings. When GAC registration is necessary
	for COM+ enabled services, LLBLGen will generate AssemblyInfo statements into the abstract base class for the
	COM+ application name and the .snk filename. These statements are commented out. LLBLGen will emit the
	common definitions of types needed in the complete namespace in the baseclass file:
	the .NET base class will contain the definition of the interface ICommonDBAccess, which is implemented by the 
	methods calling the Stored Procedures. It will also contain a definition of an enum, LLBLError, which is used
	in all .NET code classes. By default, it contains just one value, AllOk, but you can extend this enum with your
	own error codes, which you can return from the stored procedures generated (when you extend them too) and this way
	you can test reported error codes from the stored procedures in your higher level code, on a more friendlier way
	than simply test for '-1', for example. The base class is always named using this rule: 
	[Class prefix]DBInteractionBase. The filename is always following this rule: 
	[Class prefix]DBInteractionBase.[vb|cs].
	<br><br>
	<b>ICommonDBAccess interface</b><br>
	LLBLGen generates in the base class an interface which contains the common data-access methods used for each table.
	This interface is called <b>ICommonDBAccess</b>, and is first implemented using virtual / overrideable methods in the
	base class and, when the user has selected the options for generating this functionality, per class in 
	an overriding method which truely implements the method of the interface. The virtual / overrideable methods
	have just one statement which throws an NotImplementedException exception. This interface is particularly 
	handy when a certain control or piece of code should handle calls to LLBLGen generated class methods of several
	classes: use the interface instead of a true object reference. Only common methods are present in the interface, 
	methods which are related to a particular table, with a particular field for example, are not in the interface,
	since these are not shared by all classes of all tables. 
	<br><br>
	<b>Connection string providing</b><br>
	LLBLGen can emit several ways of Connection String providing. The default way is the creation of an app.config
	file which contains one element, Main.Connection which has the connection string as value. The developer can
	add this app.config file to the application which uses the generated data-access tier. Another way of Connection
	String usage is the usage of a property of the base class. Setting this property to a value results in the
	usage of that value as the connection string. When you select this option, be sure to set the connection string
	property after each creation of a data-access tier object. A third way is only available when COM+ services are
	selected, and this method uses the creation string which can be added using the COM+ explorer. For COM+ components,
	this is recommended. Be sure to use the same connection string as much as possible to make use of connection pooling
	in ADO.NET.
	<br><br>
	<b>One property for each tablefield</b><br>
	Per .NET class, thus per table, LLBLGen will generate per field used in one or more stored procedures, one property
	with get/set code. The type of the property depends on the type of the field, but is always one of the 
	System.Data.SqlTypes types. Check the table in the documentation of System.Data.SqlTypes for a complete
	list which SQLServer type is mapped on which C# / VB.NET type. All properties have check-code to avoid violations
	of limits of the used type. Each generated method needs a certain amount of properties set and will set
	zero or more properties when succeeded. When the option to generate .NET code comments is selected (recommended), LLBLGen
	will generate comments which show which properties are required for each generated method. When you use
	C# as the output language you can use the C# documentation generation feature of Visual Studio or other 
	3rd party tools to extract a handy API documentation with this information.
	<br><br>
	<b>Naming scheme of .NET classes</b><br>
	LLBLGen will use a standard for naming the generated classes and files for these classes. The class names follow this
	rule: [Class Prefix][TableName]. Example: for the table <i>my table</i> and prefix <i>C</i>, the class will be called: 
	<i>CMytable</i>, thus without the space. The filename for .NET classes is generated following this rule: [Classname].[cs|vb].
	<br><br>
	<b>Naming scheme of methods</b><br>
	Like the stored procedure names, LLBLGen will use a standard way of generating names for the methods generated in the
	.NET classes. Because all methods generated call stored procedures, the methods are named after the stored procedure
	they'll call. The standard naming scheme for the methods is like: (stored procedure name called by method) - 
	'[SP prefix][TableName]_'. Example: the stored procedure <i>pr_Foo_DeleteAllWMy_FieldLogic</i> will be called by
	the method <i>DeleteAllWMy_FieldLogic</i>, which is generated in the .NET class for the table Foo.
</p>
</BODY>
</HTML>