📄 generalusage.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<HTML>
<HEAD>
<META NAME="GENERATOR" Content="Microsoft Visual Studio 7.0">
<TITLE>LLBLGen::General usage information</TITLE>
<link rel="STYLESHEET" type="text/css" href="general.css">
</HEAD>
<BODY>
<br>
<h2>LLBLGen::General usage information</h2>
<h4>Important notes for VB.NET users</h4>
<p>
VB.NET doesn't use operator overloading. Therefor you can't use the implicit operators build into the SqlTypes
structures of the .NET framework. This can lead to some confusion how to set the properties of the generated
classes because a simply assignment will cause compiler errors. Below is a simple example where a property of
type SqlInt32 is set to the value stored in a local variable call <i>bar</i>. <i>MyClass</i> is a class
generated by LLBLGen.
<code>
<pre>
Dim foo as new MyClass()
foo.MyProperty = new SqlInt32(bar)
</pre>
</code>
To read a value from a property into a local .NET variable, you can use the 'Value' property of the SqlTypes
structures as shown in the following example:
<code>
<pre>
Dim bar as Integer
Dim foo as new MyClass()
'... code which calls foo.SelectOne()
' Read value stored in MyProperty into bar
bar = foo.MyProperty.Value
</pre>
</code>
</p>
<h4>GUI flexibility</h4>
<p>
<ul>
<li>LLBLGen tries to squeeze as much functionality out of .NET's rich and powerful API as possible.
It makes full usage of .NET's flexible form-resize features. The application starts in the minimum
size and can be resized as big as the user pleases. Per tab, zero or more controls resize with the
total screen size, to use the new gained windows size where it's needed.</li>
<li>LLBLGen serializes the current values of all the tabs to disk when the application is closed. This
way you don't have to re-select all kinds of options each time you run the application. Not all
settings are saved, only those which are not depending on the name of the catalog selected. The
settings are serialized to clsApplicationParams.out in the SOAP format. You can modify this file
by hand in any text editor. LLBLGen will check if this file is present. If it's not, LLBLGen
will open with the default settings.</li>
<li>XP-Luna style compatible. LLBLGen comes with a general .manifest file which will turn the application
in a true Luna style application for Windows XP.</li>
</ul>
</p>
<h4>Source code goodies</h4>
<p>
The sourcecode of LLBLGen includes some nice general classes which can be handy in other projects as well:
<ul>
<li>Directory selector form. LLBLGen uses a 100% .NET directory selector form to let the user pick the
destination directories for .NET classes and the T-SQL file. This form isn't relying on Internet Explorer's
shell extensions nor on .NET controls which shouldn't be used in production code. It's set up for
general usage so easy to include in your own projects.</li>
<li>Exception viewer. To view nested Exception objects, LLBLGen uses a general form to show the complete
contents of the passed in Exception object, including the nested inner Exception objects. This form is
easy to include in your own projects without any recoding.</li>
</ul>
</p>
<h4>Compiling the generated .NET classes</h4>
<p>
When you've generated the classes in the C# language, you can compile all classes into one
assembly by simply typing the following command on the commandline (Visual studio users
should execute 'vsvars32.bat' first. .NET SDK users should make sure the .NET tools are
in their shell path):
<code>
<pre>csc /out:<i>mydllname</i>.dll /target:library /optimize *.cs</pre>
</code>
This will result in a dll, <i>mydllname</i>.dll, which contains the assembly for the
generated code. Applications can now reference to this assembly and create
objects using the generated classes to interact with the database used to
generate the code.
<br><br>
When you'd have chosen VB.NET, you can follow a similar approach, instead of using csc, you
should use vbc (and use *.vb of course). However, the VB.NET compiler doesn't know any reference to the used
system assemblies, so you should add references to system.dll, system.data.dll etc.
to the compiler commandline as well. If you've Visual Studio.NET, it's easier
to just create a VB.NET library project and add all the generated classes to that
project.
</p>
<h4>App.config / Web.config</h4>
<p>
When the user selects 'Using a definition in an app.config file' under 'Connection string retrieval settings' on the
<a href="gui_netcode.htm">GUI: .NET code tab</a>, LLBLGen will generate an App.config file which will contain one
XML element, called 'Main.ConnectionString', under the <appSettings> tag. To succesfully use the generated data-access
tier, add this App.config file to the project which <i>uses</i> the generated data-access tier assembly. When that project
is a webproject, there is a Web.config file already present for that project, so you should add the Main.ConnectionString
element to an <appSettings> tag of the Web.config file. If the appSettings tag isn't present yet, you should add
that tag inside the <configuration> tag.
</p>
<h4>Thread safety</h4>
<p>
Because LLBLGen generates a <i>stateless</i> tier, there is no code in the generated classes which will provide
thread safety. In other words: sharing an instance of a LLBLGen generated class (including the ConnectionProvider
class) among different threads, isn't wise. When you keep your code stateless however, this is never an issue,
since instances of generated classes never end up in a global store where they're selected from by several threads
nor are instances shared among threads. When you select COM+ object pooling, an instance <i>is</i> stored in the
COM+ object pool, but because when an object is pooled, Deactivate is called and when an object is retrieved from
the pool, Activate is called, the 'new' object is cleaned from data and looks like a new instance, therefor
thread safety is not an issue.
</p>
<h4>Important notes for LLBLGen 1.0 users:</h4>
<p>
<ul>
<li>The method 'Select' is renamed to 'SelectOne'. Current code using the LLBLGen v1.0 generated code which has to use
the code generated by LLBLGen v1.2 will not compile, because old references to 'Select' can't find that method.
Rename in your high level business logic code all calls to 'Select' methods to calls to 'SelectOne' methods. The
renaming of this method is done because LLBLGen now also generates VB.NET code and 'Select' is a reserved keyword
in VB.NET. Because the data-access tier generated by LLBLGen should be the same in VB.NET as in C#, the method
is renamed in both the VB.NET and C# emitters. </li>
<li>The prefix of stored procedures is changed to 'pr_', since 'sp_' prefixed stored procs are slower in SQLServer,
because SQLServer will always look for these procedures in the Master database. </li>
<li>Because of the renaming of 'Select' in 'SelectOne', the called stored procedure is now also suffixed with 'SelectOne'
and not with 'Select', as in v1.0. When you generate a data-access layer with LLBLGen v1.2 for an existing codebase,
also update the stored procedures, and first remove all *_Select procedures since these will not be used anymore.</li>
</ul>
Our appologies for this inconvieniance.
</p>
<div align="right" class="SmallFontTOC">
<hr size="1" width="60%" align="right">
LLBLGen v1.21 documentation. © 2002-2003 <a href="http://www.sd.nl/" target="_blank">Solutions Design</a>
</div>
<br><br>
</BODY>
</HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -