没有合适的资源?快使用搜索试试~ 我知道了~
NHibernate ASP.NET 2.0 企业级应用案例 1/3
3星 · 超过75%的资源 需积分: 3 338 下载量 178 浏览量
2007-11-10
01:04:41
上传
评论
收藏 470KB PDF 举报
温馨提示
试读
27页
NHibernate ASP.NET 企业级应用案例。全英文。案例所用的框架很明了也很经典,还应用了很多设计模式。
资源推荐
资源详情
资源评论
All Topics, ASP.NET >> ASP.NET >> Design and Architecture (Advanced)
http://www.codeproject.com/aspnet/NHibernateBestPractices.asp
NHibernate Best Practices with
ASP.NET, 1.2nd Ed.
By Billy McCafferty.
This article describes best practices for leveraging the benefits of
NHibernate 1.2, ASP.NET, generics, and unit testing together.
C#
Windows, .NET
ASP.NET, Win32, SQL (SQL 2000),
VS, WebForms
DB, Dev
Posted : 12 Mar 2006
Updated : 2 May 2007
Views : 328,363
Prize winner: March, 2006
208 votes for this article.
Popularity: 11.31. Rating: 4.88 out of 5.
Download Basic NHibernate Sample - 1,477.9 KB
Download "Enterprise" NHibernate Sample - 2,168.9 KB
Preface to the 1.2
nd
Edition
In March of 2006 I published my initial thoughts on NHibernate best practices with ASP.NET,
generics and unit tests. I've been delighted to learn that these ideas have been implemented in a
number of real-world scenarios with strong success. Since then, I've worked with many people to
refine these ideas, learn from mistakes and leverage a more powerful version of NHibernate.
Accordingly, although only a modest, yet important, amount of modification has been made to
the underlying architecture, some other important factors have been updated and addressed in
this article:
Quite simply, NHibernate is awesome. In the previous edition of this article, I assumed you
already knew this...but I now try to convince the dissenters as well.
NHibernate 1.2 natively supports generics.
NHibernate 1.2 natively supports nullable types.
NHibernate 1.2 natively supports mapping attributes.
NHibernate 1.2 can communicate with stored procedures.
Using CallContext for ISession storage in ASP.NET was susceptible to failure under load.
Exposing a publicly settable ID property created a point-of-susceptibility.
Providing automatic parent/child wiring, via Ayende's very helpful NHibernate.Generics, was
more headache than help.
Have you used Rhino Mocks 3.0, NUnitAsp, or Fit? Well, these are all discussed with an
expanded emphasis on test-driven development.
As an alternative to my recommendations, also consider Castle Project's offerings such as
MonoRail and/or ActiveRecord for a simple yet powerful out-of-the-box framework for
ASP.NET. In fact, if it's technically feasible and you can generate buy-in on your team for
these off-the-shelf tools, I would recommend using them over a ground-up solution. But
even if you do use Castle Project facilities, this article should still have a lot of useful
information for you!
In addition to those listed above, there are other important refactorings and fixes
throughout the article and the code. This edition is by no means just a light touch-up of the
original article.
In addition to an overhaul of the original sample code, an expanded "enterprise" sample
has been included demonstrating:
NHibernate with web services
Page
1
of
27
NHibernate Best Practices with ASP.NET, 1.2nd Ed.
-
The Code Project
-
ASP.NET
11/2/2007
http://www.codeproject.com/aspnet/NHibernateBestPractices.asp?print=true
NHibernate with multiple databases
Integration with Castle Windsor
A reusable data layer for the data access components.
A simple example of Model-View-Presenter
A quick thanks goes out to those who have implemented my ideas in their own work and have
given plenty of ideas for improvement and consideration! Now onto the 1.2
nd
edition...
Article Contents
Introduction
Why Use an ORM?
Goals and Overview of Article
Running the Sample Applications
NHibernate Integration Basics
Architectural Notes
The Basic Sample Application
BasicSample.Tests with NUnit, NUnitAsp, Rhino Mocks and Fit
BasicSample.Core for Defining the Domain Layer
BasicSample.Data for Implementing NHibernate Communications
BasicSample.Web for Tying it all Together
Extending the Basics to an "Enterprise" Solution
Real-World Architecture
Beyond the Basics
Where to go from here?
Migrating from NHibernate 1.0x to 1.2
Summary of NHibernate/ASP.NET Best Practices
Introduction
Why Use an ORM?
[Author's Note: The following is an excerpt taken from a book I tinker with in my "spare" time.]
"As we look to the horizon of a decade hence, we see no silver bullet. There is no single
development, in either technology or management technique, which by itself promises even one
order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity."
These prophetic words were put forth by Frederick Brooks' in his now legendary paper,
No Silver
Bullet
, in 1986. Heeding Brooks' words to a tee, it wasn't until more than a decade later, in 1997,
that the software world was presented with a hint of an upcoming silver bullet in the form of
NeXT's Enterprise Object Framework...one of the first object-relational mappers (ORM). Although
not regularly conspicuously stated – often to avoid being seen as a heretic of software dogma – it
is commonly accepted by many that ORM technologies, when used correctly, are, in fact, a silver
bullet for software development. With the maturation of NHibernate, the ORM silver bullet has
been formally introduced to the world of .NET.
The most common dissenters of ORM technologies, in general, are developers using Microsoft
technologies. (As I've placed myself squarely into this realm for the past decade or so, I feel quite
comfortable bringing us up first!) There seems to be an unwritten rule that "if it wasn't invented
by Microsoft, then wait until Microsoft puts out the right way to do it." Stepping up to the plate,
Microsoft intends to do just that with "LINQ to Entities" in the upcoming C# 3.0. (Yes, officially
discard the use of "ObjectSpaces" and "DLINQ.") Developers may continue to wait for this
Page
2
of
27
NHibernate Best Practices with ASP.NET, 1.2nd Ed.
-
The Code Project
-
ASP.NET
11/2/2007
http://www.codeproject.com/aspnet/NHibernateBestPractices.asp?print=true
technology or, alternatively, start realizing the benefits of ORM immediately. To be fair, the not-
invented-by-Microsoft toolset for .NET developers used to be sparse but has been steadily
growing since the advent of .NET. Circa 2004, the "not created by the mothership" toolset of open
source tools finally began to reach a respectable level of maturity and should be seriously
considered for any .NET endeavor. (And since, statistically, the majority of software projects fail,
it sounds like the consideration of an expanded toolset is certainly warranted.) The impending
introduction of LINQ certainly brings great benefits to flexible querying. Fortunately, LINQ is not
exclusive to Microsoft data-access layers and
LINQ for NHibernate is already well underway by
Ayende Rahien.
Other dissenters of these technologies suggest that ORMs kill application performance and only
provide a significant improvement to productivity in the initial stages of development.
Furthermore, the argument continues, is that the use of an ORM becomes a serious detriment to
project success only later in the project, when issues of performance and maintainability begin to
have a more noticeable effect. Three obvious retorts come to mind in response to these protests.
First and foremost, in support of ORMs, using a framework such as NHibernate increases your
performance as a developer. If you can spend 90% less time (yes, I said "90% less time") on
developing data access code, then quality time can be spent improving the domain model and
tuning performance – assuming it becomes necessary. Furthermore, leveraging a simple profiling
tool goes a long way towards implicating the 5% of code that's causing 95% of the performance
bottleneck. And in the cases in which the data access layer is the bottleneck, simple adjustments
can usually be made to reap substantial improvements. Incidentally, this is no different than
when not using an ORM. (Be sure to check out Peter Weissbrod's
introductory article to profiling
NHibernate applications
.) And in the very few situations in which the ORM framework is the
bottleneck and can't be adjusted for improvement, it's trivially simple to bypass the ORM
altogether if the data access layer has been properly abstracted.
Secondly, NHibernate, specifically, provides an incredible amount of control over all aspects of
data-loading behavior. This has positive effects on developer productivity, application scalability,
and application stability. Caching is certainly available – but this is readily available in non-ORM
solutions as well. Other out-of-the-box features include lazy loading, support for inheritance,
declaration of immutable classes, loading of read-only properties, support for generics, stored
procedures, blah blah blah. The point is that all these powerful features have been proven in real-
world scenarios and, therefore, have removed many hours of developing, debugging and
tweaking a custom data access layer. (And if you really feel the need to get into the code, that's
just fine since NHibernate's an open source project.)
Finally, I would argue that those who feel that ORMs like NHibernate become maintenance
headaches later in a project are working with a coding architecture that would inhibit the
maintenance of any data access layer. Just because I've suggested that NHibernate is a silver
bullet doesn't imply that it eliminates the need for proper application design. With the proper
amount of judicious, architectural forethought, NHibernate is quite possibly the most maintainable
solution for tying a .NET application to a database.
Needless to say, NHibernate, like other ORM tools, has alleviated the maintenance of thousands
of lines of code and stored procedures, thus allowing developers to focus more attention on the
core of a project: its domain model and business logic. Even if you automatically generate your
ADO.NET data-access layer using a tool such as CodeSmith or LLBLGen Pro, NHibernate provides
the flexibility in decoupling your domain model from your relational model. Your database should
be an "implementation detail" that is defined to support your domain model, not the other way
around. The remainder of this article focuses on describing best practices for integrating
NHibernate into ASP.NET using well established design patterns and "lessons learned from the
field".
Page
3
of
27
NHibernate Best Practices with ASP.NET, 1.2nd Ed.
-
The Code Project
-
ASP.NET
11/2/2007
http://www.codeproject.com/aspnet/NHibernateBestPractices.asp?print=true
Goals and Overview of Article
This article assumes a good understanding of C# and NHibernate, knowledge of the Data Access
Object / Repository pattern, and at least a basic familiarity with Generics. Note that this article
does not focus on using NHibernate but, instead, on integrating NHibernate into ASP.NET
applications. If you're just getting acquainted with NHibernate, I'd recommend reading these two
great introductions at TheServerSide.net:
Part 1 and Part 2. (Also keep an eye out for Pierre
Kuate's forthcoming
NHibernate in Action.) For an extensive overview of the Data Access Object
pattern, which is leveraged heavily within the samples, go to
J2EE's BluePrints catalog. Although I
use the phrase "Data Access Object" (or "DAO") throughout, it is interchangeable with Eric Evans'
"Repository" in
Domain-Driven Design. I just find "DAO" more convenient to type!
In building solid data integration within an ASP.NET 2.0 application, we aim to achieve the
following objectives:
Presentation and domain layers should be in relative ignorance of how they communicate
with the database. You should be able to modify your means of data communication with
minimal modification to these layers.
Business logic should be easily testable without depending on a live database.
NHibernate features, such as lazy-loading, should be available throughout the entire ASPX
page life-cycle.
.NET 2.0 Generics should be leveraged to alleviate duplicated code.
Two sample applications have been included, demonstrating the use of NHibernate with ASP.NET
while meeting the above objectives:
Basic NHibernate Sample: This sample demonstrates the fundamentals of using NHibernate
with ASP.NET and unit tests with a simple-to-understand, but not completely reusable,
architecture.
"Enterprise" NHibernate Sample: This sample is provided with an architecturally sound
grounding using proven design patterns which should allow you to quickly reuse the
framework in almost any sized ASP.NET project. This sample also serves to demonstrate
NHibernate with ASP.NET and "a whole bunch of other stuff" including communicating with
multiple databases, using the pattern
Model-View-Presenter, setting up a simple web-
service which uses NHibernate, and integrating with
Castle Windsor. Although code is
included for communicating with multiple databases, a detailed explanation is beyond the
scope of this article and may be found at the CodeProject.com article,
Using NHibernate
with Multiple Databases
. (Note that that article's sample application is compatible with
NHibernate 1.0x; albeit, the general approach is still applicable.)
What follows now is a description of how each of the aforementioned design objectives has been
tackled in the sample applications. But before getting into the implementation details, let's skip
right to the chase and get the sample up and running.
Running the Basic NHibernate Sample
The sample application, at the risk of being terribly cliché, utilize the Northwind database within
SQL Server 2005 to view and update a listing of Northwind customers. To demonstrate the use of
lazy-loading, the application also displays the orders that each customer has made. All you need
to run the samples locally is IIS with the .NET 2.0 Framework installed, and SQL Server 2005 (or
2000) containing the Northwind database. (Since SQL Server 2005 doesn't come with Northwind
by default, you can simply backup the Northwind DB from 2000 and restore it into 2005.) The
samples also port to SQL Server 2000...simply modify the NHibernate configuration settings,
accordingly.
Page
4
of
27
NHibernate Best Practices with ASP.NET, 1.2nd Ed.
-
The Code Project
-
ASP.NET
11/2/2007
http://www.codeproject.com/aspnet/NHibernateBestPractices.asp?print=true
To get the basic NHibernate sample application up and running:
1. Unzip the sample application to the folder of your choice.
2. Create a new virtual directory within IIS. The alias should be BasicNHibernateSample, and
the directory should point to the BasicSample.Web folder that was created after unzipping
the application.
3. Open BasicSample.Web/web.config and BasicSample.Tests/App.config to modify the
database connection strings to connect to a Northwind database on Microsoft SQL Server.
4. If, and only if, you're running IIS 7, modify web.config by commenting out the "compatible
with IIS 6" section and uncomment the "compatible with IIS 7" section.
5. Open your web browser to http://localhost/BasicNHibernateSample/Default.aspx, and
you're off and running!
Steps for getting the "enterprise" sample up and running are discussed in
Extending the Basics to
an "Enterprise" Solution
. But before that, now that you're able to follow along with the basic
sample in front of you, we'll examine how the application was developed to meet our design
objectives...
NHibernate Integration Basics
When developing an application, my primary goals are to:
Write code once and only once.
Focus on simplicity and readability.
Keep coupling and dependencies to a minimum.
Maintain a clean separation of concerns.
Do all of the above using test-driven development.
This section discusses using these design principles for the integration of NHibernate into
ASP.NET applications. We'll do this by dissecting the internals of the Basic NHibernate Sample.
Architectural Notes
The basic sample should not, necessarily, be seen as a reusable framework for your own ASP.NET
application. The focus within this example application is on presenting NHibernate integration in a
simple and concise manner. If you are looking for a "ready for the real-world" architecture, be
sure to take a look at
Extending the Basics to an "Enterprise" Solution after reviewing this
section. With that said, the basic sample does present a number of best practice techniques and
design patterns:
Separated Interface
Separated Interface, also known as Dependency Inversion, is a technique for establishing a clean
separation of concerns between application tiers. This technique is
described by Martin Fowler, by
Object Mentor
, and in further detail in Robert Martin's Agile Software Development. The technique
is often used for cleanly separating a data access layer from a domain layer. For example,
assume a Customer object - in the domain layer - needs to communicate with a data access
object (DAO) to retrieve a number of past Orders. (Whether or not the domain layer should ever
communicate directly with a DOA is left for another discussion.) Consequently, the Customer
object has a dependency on the Order DAO - in the data layer. But for the Order DAO to return
orders, the DAO requires a dependency back to the domain layer.
The simplest solution is to put the data layer, containing the DAOs, into the same physical
assembly as the domain layer. To maintain a "virtual" separation of concerns, the containing
Page
5
of
27
NHibernate Best Practices with ASP.NET, 1.2nd Ed.
-
The Code Project
-
ASP.NET
11/2/2007
http://www.codeproject.com/aspnet/NHibernateBestPractices.asp?print=true
剩余26页未读,继续阅读
资源评论
- 水獭我2013-05-09我也是 web加载不上。
- t_kong2015-06-25好吧,加载不了,资源内容有问题
- liuzeming2012-01-10web加载不上。
- ddddouche2013-06-19加载不了,资源内容有问题
butthead88
- 粉丝: 0
- 资源: 3
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功