⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 codestructure.htm

📁 LLBLGen 1.21 Sourcecode
💻 HTM
📖 第 1 页 / 共 2 页
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" > 
<HTML>
<HEAD>
<META NAME="GENERATOR" Content="Microsoft Visual Studio 7.0">
<TITLE>LLBLGen::Structure of generated code</TITLE>
<link rel="STYLESHEET" type="text/css" href="general.css">
</HEAD>
<BODY>
<br>
<h3>LLBLGen::Structure of generated code</h3>
<p>
	LLBLGen generates code, and generated code is almost never truly the same as handwritten code, its style,
	format, even general structure, can be different than the way the developer usually writes code. Using the
	GUI, the user can 'tune' the way LLBLGen generates code, but there are things you can't tune with the GUI but can
	be odd at first. 
</p>
<p>
	The main design philosophy of LLBLGen is that the generated code should be as close to handwritten code as possible
	and should be extensible. This way, LLBLGen generates comments where comments are needed, uses properties
	for input of data and tries to layout the code as clean as possible. LLBLGen will use #regions to mark
	areas in the generated .NET code (VB.NET or C#) (f.e. the member declarations and the property declarations) so that users of
	Visual Studio.NET can collapse these areas. All generated code is modelled after real life hand written production 
	code and best practices experiences. When you still find the code looks	awful you can grab the sourcecode of 
	LLBLGen and manually adjust the way the output is generated. The sourcecode	is extensively commented so diving 
	into it shouldn't be a big nightmare.
</p>
<p>
	<h5>Code generator internals</h5>
	The code generator works per table or view and the generator will produce one pack of code per table or view. 
	All fields per table or view are read from SQLServer's information views to determine which fields should be 
	used for which purposes when generating the .NET and T-SQL code. Per table or view, the generator builds a 
	collection of field objects which are then per stored procedure added to the list of input parameters and 
	output parameters. 
</p>
<p>
	The generator will generate per <i>table</i> the following stored procedures (if possible):
	<ul>
		<li><b>Insert</b>. This stored procedure inserts 1 single new row.</li>
		<li><b>Delete</b>. This stored procedure deletes 1 single row, using the complete Primary Key to 
			locate the row which should be deleted.</li>
		<li><b>DeleteWPrimaryKeyFieldLogic</b>. One stored procedure per Primary Key field. These stored procedures
			are only generated when the Primary Key of the table consists of more than 1 field. This stored procedures
			will delete all rows where the particular field of the Primary Key has the value specified.</li>
		<li><b>Update</b>. This stored procedure will update 1 single row, using the complete Primary Key. 
			This stored procedure is not generated when there are no non-Primary Key fields in the table: 
			LLBLGen's code will not update Primary Key fields.</li>
		<li><b>UpdateAllWForeignKeyFieldLogic</b>. One stored procedure per Foreign Key field (which shouldn't be 
			in the Primary Key). These Update stored procedures will update all rows with the given 'old' value 
			for the Foreign Key field with the given new value for the Foreign Key field. 
			These procedures can be necessary to reset foreign key constraints.</li>
		<li><b>SelectOne</b>. This stored procedure will select 1 single row, using the complete Primary Key to locate the
			row to return.
			<br><b>Note:</b> this method is renamed
			since version 1.0, because in VB.NET 'Select' is a reserved keyword, and the generated API's should be equivalent,
			therefor the method is renamed to 'SelectOne'.</li>
		<li><b>SelectOneWUniqueFieldLogic</b>. One stored procedure per field in the table which is <i>not</i> part of the
			Primary Key, but has a UNIQUE constraint or is an Identity field or a RowGUID column. These stored procedures
			will use the UniqueField to locate the particular row to return.</li>
		<li><b>SelectAll</b>. This stored procedure will select simply all rows in the table, ordered by the 
			Primary Key Fields, ascending. If no Primary Key fields are present, no ordering is performed.</li>
		<li><b>SelectAllWForeignKeyLogic</b>. One stored procedure per Foreign Key field in the table. 
			These stored procedurs will select all rows which have the given value for the Foreign Key field.</li>
	</ul>
	The generator will generate per <i>view</i> the following stored procedures (if possible):
	<ul>
		<li><b>Insert</b>. This stored procedure inserts 1 single new row.</li>
		<li><b>SelectAll</b>. This stored procedure will select simply all rows in the table. Since views don't have any
			Primary Keys, no ordering is performed.</li>
	</ul>
	For each processed table and view, LLBLGen generates a .NET class in the selected language (C# or VB.NET).
	For each generated Stored Procedure there will be 1 .NET class method in the table/view's .NET class (C# or VB.NET). 
	Per table or view, per Stored Procedure type, LLBLGen determines which fields should be input parameters for the Stored 
	Procedure and which fields should be output parameters. These lists are also used to build the methods' .NET code to create 
	the right SqlParameter creation lists. 
	<br><br>
	To be able to determine which Foreign Key - Primary Key relations are present, LLBLGen needs a database where
	Foreign Key constraints and Primary Key's are already defined. It's good practise to create these,
	just after the table layouts are defined. Databases with no Primary Keys nor Foreign Key constraints can't be
	used to generate a solid data-access layer because LLBLGen doesn't know which fields are the Primary Key nor
	will it be able to determine which fields in which tables are Foreign Keys. If you use 'shadow keys', which are fields
	which are also used to select particular rows from the table, check if a UNIQUE constraint can be applied to these fields,
	so LLBLGen can generate a SelectOne type stored procedure for these fields.
</p>
<p>
	<h5>T-SQL Stored procedures</h5>
	The T-SQL Code generated is placed in one file, to make it easier to import the Stored Procedure code into a
	database. All T-SQL code is specified using SQLServer 7 '[' and ']' markers for parameters and Stored Procedure names,
	plus all names are prefixed with '[dbo].', so all users will be able to use the generated Stored Procedures plus 
	these prefixes will prevent unnecessary recompilations of Stored Procedures. Identity values are determined using
	SCOPE_IDENTITY() (SQLServer 2000) or @@IDENTITY (SQLServer 7), so insert triggers defined on tables are not affecting 
	the retrieval of Identity values. Identity values are returned by the Stored Procedures. When selected in the GUI, 
	LLBLGen will also generate an ErrorCode parameter as output parameter for every Stored Procedure generated. 
	The value of @@ERROR is returned in this variable. 
	<br><br>
	<b>Exclusion of fields</b><br>
	LLBLGen supports exclusion of one or more fields, so these fields will not turn up in input parameter lists for
	Stored Procedures for insertion and update of rows. For example a field 'CreateDate' which represents a
	datetime field with the date/time on which the record was created, can be filled directly with a default
	value in the Stored Procedure. By excluding this field 'CreateDate' from insert and update queries, LLBLGen
	will assign to this field the default value for a datetime field, which is GETDATE(). All rows updated or inserted
	will then have the accurate value for CreateDate automatically.
	See <a href="ref_types.htm">SQLServer, .NET type relations</a> for a complete list of default
	values per supported type.
	<br><br>
	<b>Database NULL values</b><br>
	Allthough NULL values in databases should be avoided for most purposes, some people say they need them, so LLBLGen supports
	NULL values for fields. A developer should select NULL value support in the GUI to omit the NULL value checks
	on fields which allow NULL values. 
	<br><br>
	<b>Naming scheme of stored procedures</b><br>
	LLBLGen will name the stored procedures generated in a standarized way, so you can find back the correct stored procedure
	easily in the generated set. The following table describes the different stored procedures using an example table 'Foo'
	with field 'My Field'. Take note of the space in 'My Field'. 
	<br clear="all">
	<table border="1" cellpadding="2" cellspacing="0">
		<tr bgcolor="LightGrey">
			<td class="TDSmallerfont"><b>SP Type</b></td>
			<td class="TDSmallerfont"><b>SP Naming syntax</b></td>
			<td class="TDSmallerfont"><b>SP Example</b></td>
		</tr>
		<tr>

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -