[Reference]NHibernate Best Practices with ASP.NET, 1.2nd Ed.

http://www.codeproject.com/aspnet/NHibernateBestPractices.asp

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
- 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?

[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 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".

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.

To get the basic NHibernate sample application up and running:

Unzip the sample application to the folder of your choice.
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.
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.
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.
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 project could include two folders, one named Domain and the other named Data. (I've actually used this approach on a good-sized project, in a former life, with regrettable consequences.) This approach brings with it a number of ill effects:

The domain and data layers share a bi-directional dependency with each other.
There's nothing to prevent the data layer from bleeding into the domain layer and vice-versa. If it can't be structurally prevented then it will occur.
It's difficult to unit test the domain layer without using a live database to support the data layer. Among other drawbacks, this brings unit testing performance to a crawl; therefore, developers stop unit testing.

Alternatively, the domain and data layers could be placed into physically separate assemblies; e.g., Project.Core and Project.Data, respectively. The domain layer (the Project.Core assembly) would contain domain objects and DAO interfaces. The data layer (the Project.Data assembly) would contain concrete implementations of the DAO interfaces defined in the domain layer. This is shown in the package diagram below. Note that the arrow signifies a uni-directional dependency from the data layer to the domain layer.

This clean separation brings with it a number of benefits:

Developers are structurally unable to put concrete data-access code into the domain layer without adding a number of easy-to-spot references, such as to NHibernate or System.Data.SqlClient.
The domain layer remains in ignorant bliss of how the data layer communicates or with who it communicates. Therefore, it's easier to switch out the data-access implementation details (e.g., from ADO.NET to NHibernate) without having to modify the domain layer.
Having dependencies on interfaces makes it easy to provide a "mocked" data-access layer to the domain layer while unit testing. This keeps unit tests blazing fast and eliminates the need to maintain test data in the database.

An implementation example of Separated Interface is included in the sample applications and is discussed further below.

Dependency Injection

Separated Interface, as described above, introduces a dilemma: how are the concrete DAO implementations given to the domain layer which only "knows" about interfaces? Dependency Injection, also known as Inversion of Control (IoC), describes the technique for doing this. With Dependency Injection, it's possible to remove many direct instantiations of concrete objects along with the inflexibility that comes along with calling the new keyword directly. Dependency Injection may be performed manually or via an IoC Container. The manual approach is performed by simply passing an object's "service dependencies" to it via its constructor or via property setters. I've written an introduction to this approach within the CodeProject article, Dependency Injection for Loose Coupling. (Note that a "service dependency" may be a DAO, an emailing utility, or anything that leverages external, expensive, or shouldn't-be-used-in-unit-test resources.) This manual approach is most useful within unit tests because the explicitness of passing concrete dependencies is helpful in describing functionality. (Martin Fowler has some wise words on the value of being explicit.) Alternatively, dependency injection may be performed via an IoC Container driven by code or XML. (Fowler has also written a great introduction to IoC Containers, service locators and making an appropriate choice between the two.) Think of IoC Containers as providing decoupling on steroids. The benefits of an IoC Container include a flexible, loosely-coupled framework and an increased emphasis on coding-to-interface. The drawback is an added layer of complexity within the application. This is one of the many trade-offs between flexibility and complexity which needs to be considered when developing an application. Here are two great tools for putting IoC Containers into practice:

Castle Windsor: The Castle Windsor, IoC Container provides great IoC support using a combination of XML configuration and strongly typed declarations. Some of the advantages Castle Windsor brings to the table are less XML and more compile-time error catching, when compared against other options. The Castle Project also has a number of other powerful modules, making it an attractive option if you're looking for more than just IoC. Wide support has been shown for this IoC Container which has generated a lot of buzz around the .NET development community. The "Enterprise" NHibernate Sample includes an example of using Castle Windsor.
Spring .NET: This framework provides IoC declared via XML configuration files. Like the Castle Project, Spring.NET also provides a wide assortment of additional development utilities. This option should be particularly attractive for developers coming from the Java world and are already familiar with the Spring Framework.

I've found that using an IoC Container is most useful outside of unit tests for enabling ASPX pages to be given dependencies, to avoid ever having to call the new keyword directly. This may be taken further to wire up dependencies within a presenters-layer or service layer, as well.

Design by Contract

Design-by-Contract (DBC) is quite simply the best way to never have to use the debugger again. Although infrequently discussed, this technique should be given the same amount of praise that test-driven development receives. (Not that I'm saying that DBC gets jealous, but it should.) It increases quality, reduces checks for null, reduces debugging time, and greatly improves the overall stability of an application. To be more technically descriptive, DBC is a technique for contractually obligating users of your code (which is usually you, yourself) to use methods and properties in a particular way and for those methods and properties to promise to successfully carry out the given request. If the contract is not followed, an exception is thrown. It may seem a bit drastic at first, but it goes a long way to improving code quality. With DBC, "pre-conditions" assert what contractual obligations must be adhered to when invoking a method or property. "Post-conditions" assert what contractual obligations have been ensured. I highly recommend reading an introduction to Design-by-Contract; you'll be hooked on using it very quickly. The sample projects included with this article use a modified DBC class originally written by Kevin McFarlane. The original allows conditional compilation for turning contracts on for debug mode and off for release mode while the variation included in this article's samples maintains contractual obligations regardless of compilation mode. In my opinion, a contract is always a contract and the behavior should never vary.

In the code, you'll find that pre-conditions are declared with Check.Require while post-condition are declared with Check.Ensure. As DBC is not domain-specific, this class is appropriately pulled out into a reusable, utilities library in the "enterprise" sample.

The Basic Sample Application

So what are we working with here? The basic application fulfills the following user stories:

User may view listing of suppliers and their products.
User may view listing of existing customers.
User may view details of customer.
User may view a listing of past orders placed by a customer.
User may view a listing of order summaries, including product name and total quantity, placed by a customer.
User may edit customer details.
User may add a new customer.

Regardless of how valuable this application may or may not be, the above user stories are enough to demonstrate the primary aspects of NHibernate integration. To assist with keeping logical tiers loosely coupled, the included sample application is split into four projects: Tests, Web, Core and Data. As a policy, I use <ProjectName>.<LayerName> for naming projects; e.g., BasicSample.Data. Although this simple separation of concerns will work for now, a more realistic architecture will be discussed later. In peeling the layers of the onion, let's begin with the testing layer and work our way towards the simple presentation layer.

BasicSample.Tests with NUnit, NUnitAsp, Rhino Mocks and Fit

I'll assume you can probably guess what this project is for. In the first edition of this article, unit testing was only lightly discussed. As industry, and personal, experience has proven, test-driven development is a pivotal factor in producing high quality products which are more adaptable to change. Furthermore, taking a test-driven approach tends to produce better designs and, as a side effect, creates a lot of perfectly valid technical documentation. For a terrific beginner's introduction to a "day in the life" of test-driven development, take a look at Kent Beck's Test-Driven Development: By Example. Examining the unit tests of the sample application provides an overview of how the application is structured and what functionality is available. After taking a look at the unit tests, we'll delve further into the code they test.

A Note on Unit Test Performance

It's imperative for unit tests to be blazing fast. If a suite of unit tests takes too long to run, developers stop running them - and we want them running unit tests all the time! In fact, if a test takes more than 0.1 second to run, the test is probably too slow. Now, if you've done unit testing in the past, you know that any unit test requiring access to a live database takes much longer than this to run. With NUnit, you can put tests into categories, making it easy to run different groups of tests at a time, thus excluding the tests that connect to a database most of the time. But at the very least, these "slow" tests should be run every night within a Continuous Integration environment. Here's a quick example of categorizing an NUnit, unit test:

[TestFixture]

[Category("Database Tests")]

public class SomeTests

{

[Test]

public void TestSomethingThatDependsOnDb() { ... }

}

Domain Layer Unit Tests

For simplicity, the domain layer of this application is light, to say the least. But even in the lightest of domain layers, it's important to have, at a minimum, every non-exception path covered by a unit test. The domain layer tests may be found in the namespace BasicSample.Tests.Domain. (As a side, is it overkill that CustomerTests.CanCreateCustomer tests the getter/setter of almost every property? It's startling how many trivial bugs you catch in the process.) While reviewing the tests, you may notice the class DomainObjectIdSetter.cs; the motivations for this class will be discussed later.

To run the unit tests, open NUnit, go to File/Open Project and open BasicSample.Tests/bin/Debug/BasicSample.Tests.dll. To prevent the more time-consuming tests from running, go to the Categories tab within NUnit and double-click both "Database Tests" and "Web Smoke Tests." Additionally, click "Exclude these categories" at the bottom. Now, when you run the unit tests, only the domain logic tests will run and not be slowed down by HTTP and database access tests. For such a small application, the added overhead of the "slow" tests is almost negligible, but can add many minutes to running the unit tests of larger apps.

Using Test Doubles for the Data Access Layer

Before getting into simulating the database layer, it should be noted that a nomenclature exists for describing different types of simulated services. Dummies, fakes, stubs and mocks are all used to describe different types of simulated behavior. An overview of the differences highlights a few which will be included in Gerard Meszaros' upcoming XUnit Test Patterns. Meszaros offers "test double" to generically describe any of these behaviors. Stubs and mocks are two such test doubles demonstrated in the sample code.

Unless you're specifically testing DAO classes, you usually don't want to run unit tests that are dependent on a live database. They're slow and volatile by nature; i.e., if the data changes, the tests break. And when testing domain logic, unit tests shouldn't break if the database changes. But the major obstacle is that domain objects themselves may depend on DAOs. Using the abstract factory pattern that is in place in the sample (discussed later), and the associated DAO interfaces, we can inject DAO test doubles into the domain objects, thereby simulating communications with the database. An example is included in the test CustomerTests.CanGetOrdersOrderedOnDateUsingStubbedDao. The following snippet, from the unit test, creates the DAO stub and injects it into customer via a public setter. Since the setter only expects an implementation of the IOrderDao interface, the stub DAO easily replaces all of the live-database behavior.

Customer customer = new Customer("Acme Anvils");

customer.ID = "ACME";

customer.OrderDao = new OrderDaoStub();

As an alternative to writing DAO stubs, which are generally static by nature and often amount to quite a bit of "not implemented" code, it is also possible to mock the DAO using a tool such as Rhino Mocks or NMock. Either selection works perfectly well, but Rhino Mocks invokes methods in a strongly typed manner as opposed to using strings, as NMock does. This makes its usage compile-time checked and assists with renaming properties and methods. The test CustomerTests.CanGetOrdersOrderedOnDateUsingMockedDao demonstrates using Rhino Mocks 3.0 to create a mocked IOrderDao. Although setting up a mocked object appears more complicated than setting up a stub, the added flexibility and greatly reduced "not implemented" code are convincing benefits. The following code, found in the class MockOrderDaoFactory.cs, shows how IOrderDao is mocked with Rhino Mocks. It essentially creates a "static" mock, or stub, in the fact that it doesn't matter what is passed in for arguments; it'll always return the same example orders created by TestOrdersFactory. But mocking with Rhino Mocks isn't limited to dumb reflexes, such as this, and can be as variably responsive as required.

public IOrderDao CreateMockOrderDao() {

MockRepository mocks = new MockRepository();

IOrderDao mockedOrderDao = mocks.CreateMock<IOrderDao>();

Expect.Call(mockedOrderDao.GetByExample(null)).IgnoreArguments()

.Return(new TestOrdersFactory().CreateOrders());

mocks.Replay(mockedOrderDao);

return mockedOrderDao;

}

Unfortunately, more often than not, you're maintaining legacy code that has no semblance of the ideal "code-to-interface" that allows for such test-double injection. Usually, there are many explicit dependencies to concrete objects, and it is difficult to replace data-access objects with test doubles to simulate a live database. In these situations, your options are to either refactor the legacy code to fit within a test harness, or to use an object mocking tool such as TypeMock. With TypeMock, it is even possible to mock sealed and singleton classes - an impressive feat to pull off without such a tool. Albeit powerful, TypeMock is best left alone unless absolutely needed; using TypeMock prematurely makes it tempting to not code to interface. The more appropriate course to take when working with legacy code - time and budget permitting - is to refactor the code for greater flexibility. Working Effectively with Legacy Code by Michael Feathers is full of great ideas for refactoring legacy code into a test harness.

Unit Testing NHibernate DAOs

In the previous edition of this article, NHibernate's ISession was stored and retrieved solely via System.Runtime.Remoting.Messaging.CallContext. Although perfectly fine for WinForms and NUnit tests, this is a very bad idea for ASP.NET as the ISession may be "lost" under load. (These two articles provide further explanation for why using CallContext in ASP.NET applications is a bad idea.) For proper integration with ASP.NET applications, the ISession should be stored in HttpContext.Current.Items; but doing so forces you to simulate an HTTP context when running unit tests. It also prevents the framework from easily porting to WinForms. A better approach is to use the proper repository when appropriate. So if a web context is available, then use HttpContext; otherwise, use CallContext. Implementation details of this combined approach are discussed later. (A thanks goes out to the many people in the article comments that raised this concern.) Take a look at BasicSample.Tests/Data/CustomerDaoTests.cs for unit tests that are HTTP-agnostic with respect to how the ISession is managed. As a side, as you'll see in the unit test, unless you want data changes made within your tests to be committed to the database, it's a good idea to rollback the transaction.

As demonstrated in the sample, it's possible to create a generic DAO that works for any persistent object. (Details of which will be discussed later.) This leads to the discussion of what should be tested and how should it be done? Should each concrete DAO be fully tested? How is the test data maintained? Personal experience suggests these guidelines:

Make sure a unit test exists to test each method of the generic DAO, once. For example, if you have 10 DAOs which implement the generic DAO, only one of them needs to be fully tested for each method. Unit testing the other nine implementations of the generic DAO will provide little added value.
Make sure a unit test exists to test each extension method to the generic DAO. For example, if you have a CustomerDao class which inherits from the generic DAO and then extend it with an additional method, such as GetActiveCustomers(), then a unit test should be written to test this extension method.
Make sure a unit test exists to fully test each "specialty" DAO. For instance, the DAO BasicSample.Data/HistoricalOrderSummaryDao.cs does not inherit from the generic DAO and would be considered a specialty DAO. Therefore, a unit test exists to test each of its methods.
Use a tool such as NDbUnit to put the test database into a known state both before and after DAO unit tests are run.
Always remember, unit tests should never depend on the actions of another unit test! They should be independent and able to be run in isolation. E.g., a delete-test should not depend on the previous insert-test having successfully completed. Note that TestFixtureSetUp, and other setup/teardown methods, are OK to run while still being able to consider the test to have run in isolation.

Using Fit Test Doubles for the Presentation Layer

When the domain layer was tested, test doubles were used to simulate NHibernate communications with the database. Similarly, it's handy at times to use this same approach when testing the presentation layer. Suppose you're working on an ASP.NET project with a dedicated "creative" team. The creative folks, with their black turtlenecks, are in charge of developing the look and feel of the application. While they're working on the graphical layout, you shouldn't be hindered to develop a presentation layer for viewing domain-logic & data-access results and for getting client feedback, while still being able to put off decisions such as master-page setup, security enforcement, and other presentation-specific decisions. In another scenario, suppose you're working on a number of complicated business rules which you'd like the client to be able to verify without having to write a few dozen unit tests to encapsulate each minor variation. FIT (Framework for Integrated Test) is a tool for developers to fake the presentation layer very quickly and provide for a more collaborative effort between developers and project stakeholders. As the Fit site states, this is done "to learn what the software should do and what it does do. It automatically compares customers' expectations to actual results." Arguably, a tool such as this isn't "basic" and isn't required for testing NHibernate; but the importance of test-driven development needs to be emphasized and a tool such as Fit, when used appropriately, is just as applicable to software quality as NUnit.

For viewing Fit test results, you can use WinFITRunnerLite, which runs Fit tests in a Windows client similar to NUnit, or FitNesse, which provides a web-based wiki for modifying test inputs and viewing Fit test results. Although it takes a little more setup, FitNesse provides a very flexible framework for allowing clients to participate in validating coding logic and application workflow. The following screenshot shows a simple example of the output you'd expect to see from running a calculator test with FitNesse:

Although implementation examples of Fit tests are beyond the scope of this article, my hope is that you'll get interested in learning more about this powerful framework. In addition to the websites listed previously, extensive information concerning the use of Fit and FitLibrary, an extension to Fit, may be found in Fit for Developing Software by Rick Mugridge and Ward Cunningham.

Running ASPX "Smoke Tests" with NUnitAsp

At this point, we've unit tested the domain layer and the data-access layer and learned about testing with a rough presentation layer, using Fit, for getting clients more involved. It's now time to test the ASPX pages themselves. NUnitAsp is a class library for performing these types of unit tests. Although you can get rather sophisticated using NUnitAsp with your WebForms testing, I find that NUnitAsp is best for running "smoke tests" from the continuous integration server to verify that no page is blatantly breaking. Taking NUnitAsp further than this tends to result in a lot of maintenance of the associated unit testing code. Since these HTTP unit tests are slow by nature, they're rarely run and, consequently, lightly maintained; therefore, they should be kept as simple as possible. BasicSample.Tests/Web/WebSmokeTests.cs demonstrates a sampling of these unit tests. Although trivially simple, these smoke tests go a long way towards verifying that your presentation layer is responsive, that database communications are working correctly, and that NHibernate HBMs are, for the most part, error-free. As an added bonus, if the smoke tests are directed at the production environment immediately after a deployment, they serve to pre-load all the ASPX pages for a more responsive experience for the very next visitor. You should include a smoke test for every URL-accessible web page in your application. To help organize them, create a separate test class for each grouping of smoke tests. For example, all the smoke tests for an admin section of the website would be found in a file called AdminSmokeTests.cs.

BasicSample.Core for Defining the Domain Layer

The BasicSample.Core project contains the domain model and NHibernate HBM files. This project also contains interfaces, describing the data access objects, in the BasicSample.Core.DataInterfaces namespace. (Arguably, the HBM files logically belong in the BasicSample.Data assembly, but the maintenance convenience of having the HBM files physically close to the domain objects they describe far outweighs this break in encapsulation.)

Separated Interface, Implemented

You'll notice that the BasicSample.Core project does not contain implementation details of data access objects, only interfaces describing the services it needs. The concrete DAO classes, which implement these interfaces, are found within BasicSample.Data. As described previously, this technique is called Separated Interface. If you consider BasicSample.Core to be an "upper-level layer" and BasicSample.Data to be a "lower-level layer", then, as Robert Martin describes, "each of the upper-level layers declares an abstract interface for the services that it needs. The lower-level layers are then realized from these abstract interfaces. ... Thus, the upper layers do not depend on the lower layers. Instead, the lower layers depend on abstract service interfaces declared in the upper layers".

To see this in action, the data interfaces are described in the namespace BasicSample.Core.DataInterfaces. IDao is a generic interface for providing typical data access functionality. IDaoFactory then acts as an interface for one or more DAO factory classes. Coding to the IDaoFactory interface allows you to create one concrete DAO factory for production code, and another concrete DAO factory for returning DAO test doubles for unit testing purposes. (This is an example of using the abstract factory pattern.) And as previously examined in BasicSample.Tests, leveraging mock objects in unit tests provides a means for testing a single responsibility at a time.

Collection Generics Examined

By far, one of the greatest benefits that C# 2.0 has brought to the table is the inclusion of generics. With generics, more code reuse can be effectively realized while still enforcing strongly typed coding "contracts". In the previous edition of this article, Ayende's very useful, but deprecated, NHibernate.Generics was used to integrate NHibernate with .NET generics. But now that NHibernate 1.2 natively supports generics, this class library is no longer necessary. If you've used Ayende's library in the past, you've got a bit of work ahead of you to completely migrate away from it, especially if you used the automatic wiring for managing parent/child relationships. But don't let this stop you as you can still upgrade to NHibernate 1.2 without having to immediately refactor out the automatic wiring...but you'll still want to do so sooner rather than later. More information about the steps required to refactor away from Ayende's NHibernate.Generics is found below in Migrating from NHibernate 1.0x to 1.2. A drawback to Ayende's NHibernate.Generics was that internal collections needed to be exposed with both getters and setters. This broke encapsulation and allowed collections to be manipulated or modified in unintended ways - think of it as collection harassment. Now that NHibernate supports generics natively, better collection encapsulation techniques may be employed. The following code from Customer.cs and Customer.hbm.xml shows a better encapsulation of generic collections.

public IList<Order> Orders {

get { return new List<Order>(orders).AsReadOnly(); }

protected set { orders = value; }

}

public void AddOrder(Order order) {

if (order != null && !orders.Contains(order)) {

orders.Add(order);

}

}

public void RemoveOrder(Order order) {

if (orders.Contains(order)) {

orders.Remove(order);

}

}

private IList<Order> orders = new List<Order>();

<bag name="orders" table="Orders" inverse="true" cascade="all">

<key column="CustomerID" />

<one-to-many class="BasicSample.Core.Domain.Order, BasicSample.Core" />

</bag>

Setting the orders collection setter to protected allows NHibernate to populate the collection without having to depend on a private member directly and without having to expose the setter publicly. Alternatively, the NHibernate setting access="field" could be used to set a private member directly, but the use of this should be carefully considered and only used when warranted. In the sample code above, note what AddOrder and RemoveOrder have done to the Customer class. They've shamelessly polluted the class by adding collection management concerns to the containing class. Imagine the headache this would turn into if Customer ended up having a number of collections along with methods for managing each one. In instances like this, it's usually best to employ a custom collection.

As a simple example of using a custom collection, the Supplier class may have a number of Product items associated with it. The caveat is that NHibernate needs to map to an IList collection; consequently, two collections are maintained. The first is the products collection itself, which NHibernate is aware of, and the second is a products collection wrapper which exposes the custom collection. The following code from Supplier.cs and Products.cs demonstrates this.

// Within Supplier.cs...

public Products Products {

get {

if (productsWrapper == null) {

productsWrapper = new Products(products);

}

return productsWrapper;

}

}

private Products productsWrapper;

// NHibernate binds directly to this member by the access="field" setting

private IList


 
    products = new List<Product>();

// Within Products.cs

public Products(IList


 
    products) {

this.products = products;

}

public void Add(Product product) {

if (product != null && !products.Contains(product)) {

products.Add(product);

}

}

private IList


 
    products;

Although simplistic, the example code should cover most of your custom collection needs. But in some cases, a full-blown generic, custom collection is required. One of the most common scenarios includes creating a custom collection which implements BindingList. In these types of situations, it's necessary to leverage NHibernate's IUserCollectionType. A good example of implementing this may be found here.

Generic IDs and Object Comparisons

In BasicSample.Core, each persistable domain object inherits from DomainObject. This class handles most of the work involved with comparing two domain objects for equality. (A detailed discussion of this object may be found in a devlicio.us blog post.) DomainObject is also a generic class which accepts a data type declaring the ID type of the domain object. This generic property provides the ability to have one domain object which uses a string as an ID, such as Customer, and another to have a long as an ID, such as Order. It should be duly noted that in the previous edition of this article, the ID property had both a public getter and setter. Although the getter is essential, the public setter opened Pandora's box for corrupting existing data. Assume you retrieved a customer from the database and accidentally set its ID to another customer's ID. When the customer gets saved back to the database, its data overwrites that of the other customer. For a more subtle example, assume the Customer class is being used as a pseudo DTO being returned from an edit screen. With a public ID setter, the developer sets the ID and the applicable properties and returns it to another object which takes care of transferring the DTO information to the "real" customer pulled from the database. Mind you, both the DTO and the "real" customer are being passed around as instances of Customer. So if, during maintenance, a developer doesn't realize that the Customer being returned from the view should be treated as a DTO and not as a "real" customer, and proceeds to invoke save on it directly, then it's quite probable that a lot of live customer data has been lost since it was overwritten with the sparse DTO data. The primary weakness behind this is the fact that ID had a public setter. Therefore, it is best that a domain object's ID only be set by NHibernate when loading an object from the database and is hidden from public setting. But there are situations wherein a domain object has an assigned ID. (Personally, I find no place for assigned IDs and avoid them whenever possible, but understand that an argument can be made for their use. You can find a further rant in BasicSample.Web/AddCustomer.aspx.) For situations when an assigned ID is required, an interface is included called IHasAssignedId. This interface defines a method for setting the ID. So although it provides a doorway for setting the ID, it requires a bit more thought concerning its use and provides a good spot for including ID-assignment business logic. The following snippet exemplifies this within the Customer class.

public class Customer : DomainObject<string>, IHasAssignedId<string>

{

public void SetAssignedIdTo(string assignedId) {

Check.Require(!string.IsNullOrEmpty(assignedId),

"assignedId may not be null or empty");

// As an alternative to Check.Require, 

the Validation Application Block could be used for the following

Check.Require(assignedId.Trim().Length == 5,

"assignedId must be exactly 5 characters");

ID = assignedId.Trim().ToUpper();

}

...

}

An obvious drawback to not exposing a public ID setter is that this property becomes essentially unusable to the unit testing framework, unless NHibernate is used to load the object. To skirt this problem, the class BasicSample.Tests/Domain/DomainObjectIdSetter.cs enables you to set the ID of domain objects, even if they do not implement IHasAssignedId. This ability opens many testing possibilities without having to provide a public setter to the ID property. On the flipside, using reflection to set private members, for the benefit of unit tests, should be seen as a non-standard practice and used only when absolutely necessary. It adds complexity and is fragile since it is string based. But for setting the ID property of domain objects, it's a perfect fit for the unit testing layer.

Mapping the Domain to the Database

NHibernate provides two means of mapping domain objects to the database: HBMs using XML and mapping attributes. The primary advantage of HBM-XML files is that they are physically separated from the domain objects they describe. This enables the domain objects to remain as POCOs (plain old C# objects), relatively oblivious to how they are associated with the database. But keeping the mapping information separated from the domain objects may also be seen as the primary disadvantage of HBMs in that it requires additional maintenance effort to keep switching between HBMs and the classes they map. (Some people also loathe using XML.) Mapping attributes, on the other hand, are intimately connected to the domain objects and are generally less verbose than their HBM equivalents. Using mapping attributes makes the domain objects more akin to Active Records than POCOs. (For true Active Record support, consider using Castle Project's ActiveRecord.) Besides "dirtying" up the domain objects, mapping attributes require a reference to NHibernate.Mapping.Attributes which makes the domain layer a bit less data-access-provider agnostic. On the other hand, do you often find yourself switching out data-access layers completely, anyway? But as a general rule, the domain layer should remain as data-access-provider agnostic as is practical for the design goals of the application. When it comes right down to it, it's a matter of personal preference when deciding between HBMs or mapping attributes. Regardless, when starting a new project, it should be decided which technique will be used; mixing the techniques may lead to confusion as it may not be clear which objects are mapped and which are not. The sample application demonstrates using HBMs for the mapping solution. The following snippet - not found in the sample application - shows an example of using mapping attributes instead of HBMs. Additional information concerning mapping attributes may be found in the NHibernate docs.

[NHibernate.Mapping.Attributes.Class]

public class Customer

{

[NHibernate.Mapping.Attributes.Property]

public string FirstName { ... }

...

}

NHibernate Support for Nullables

A new capability that NHibernate 1.2 brings to the table is support for nullable types. Previously, a reference to Nullables.NHibernate supported nullable types, but it is no longer needed. There's no need to treat nullable property mappings, within the HBMs, any differently than other property mappings; simply map the nullable property as you would any other. NHibernate is smart enough to transfer null between the database and the nullable property it maps to. Take a look at BasicSample.Core/Domain/Order.cs for an example of using a nullable DateTime. Although support for nullables is now trivially simple to implement, it should only be used after careful consideration. My own experiences have led me to hardly ever create columns in the database which allow null. In my opinion, mapping null to primitive types has little meaning within the database nor within the domain layer. Nullable DateTime properties are about the only exception that come to mind. Obviously, there are plenty of valid situations for using null with non-primitive relationships; but even then, use of the Null Object pattern is a great alternative to checks for null scattered about the code.

NHibernate Support for Stored Procedures

NHibernate 1.2's support for stored procedures is a critical addition to this framework's capabilities. But what's so great about integrating with stored procs if all the CRUD is already taken care of by NHibernate? Two reasons: working with legacy databases and performing reporting queries. Creating a stored procedure to return query-intensive reporting data is the optimal way for polling the database. To illustrate, the Northwind database maintains orders placed by each customer. Assume you need to return the quantity of each product ever ordered by a specific customer. The class BasicSample.Core/Domain/HistoricalOrderSummary.cs is a value object which encapsulates this summary information. Note that this class does not inherit from DomainObject and does not have a corresponding HBM file. This is considered an "unmanaged" class from NHibernate's perspective, not to be confused with unmanaged C#. The file HistoricalOrderSummary.hbm.xml declares a named query which makes a call to the stored procedure CustOrderHist for returning the needed reporting data. (Details of how this data is converted into domain objects will be discussed next, while dissecting the BasicSample.Data project.)

Providing capabilities for interacting with stored procedures brings up the issue of deciding what should be performed by stored procedures and what should be performed by the domain layer. As an alternative to the stored proc, to meet the previously stated requirements, the C# code could have retrieved all the orders placed by the given customer, looped through all of them and summed the quantity of each product. But it was clear that having SQL Server perform this summing was far more efficient; imagine if the customer had placed thousands of orders. If, on the other hand, performance analysis had shown little difference in efficiency between letting the domain layer do the work vs. a stored procedure, then go with the domain layer to do the work. You'll find that this will lend itself to a more complete domain-driven design and better reusability of the resulting code. As is frequently encountered during development, this is a balance between better domain-driven design and optimized performance ... always lean towards the domain until a bottleneck is discovered. (As mentioned in the introduction, see Peter Weissbrod's article for an introduction to identifying NHibernate related bottlenecks.) Incidentally, the first NHibernate project I was involved with, which was about 50,000 LOC, required about six stored procedures in all to help optimize the data-querying capabilities. This should serve to illustrate how much you can put into the domain layer without taking an appreciable hit to performance.

BasicSample.Data for Implementing NHibernate Communications

The BasicSample.Data project contains the concrete DAOs and implementation details for communicating with the database and managing NHibernate sessions.

The DAO Factory and Generic DAO

The DAO factory and generic DAO objects have been implemented as NHibernateDaoFactory and AbstractNHibernateDao, respectively. With a few key modifications, these are C# ports of the Java versions described in detail at Hibernate's website. I highly recommend reviewing this article in detail. (Note that a bug has been fixed from the previous edition of this article wherein calling CommitChanges(), when a transaction was not being used, was not flushing the session; see AbstractNHibernateDao.CommitChanges for the fixed code. Additionally, due to NHibernate 1.2's native support of generics, DAO list results may now be retured directly without first going through a convert-to-generic-list process.) The most impressive thing to note, by using a generic DAO, is that it takes just a few lines of code to create a full-blown DAO ready for use:

Add a new inline interface, and associated retrieval method, to BasicSample.Core/DataInterfaces/IDaoFactory.cs.
Add a new inline implementation for the new DAO, and retrieval method, to BasicSample.Data/NHibernateDaoFactory.cs.

Looking at the ICustomerDao/CustomerDao example in the basic sample application, it took about five lines of code to define the interface and implement the concrete DAO ... not too bad.

Occasionally, it's necessary to extend the abstract, generic DAO with specialty methods. The interface BasicSample.Core/DataInterfaces/IOrderDao.cs defines one such example. In this case, the domain layer needs the orders-DAO to return all the orders found within a given date range. For manageability, any DAOs which extend the abstract DAO should be placed in their own file and not declared inline as ICustomerDao was. Likewise, this also applies to the concrete implementation demonstrated with BasicSample.Data/OrderDao.cs.

Retrieving Reporting Data from Stored Procs

While examining the BasicSample.Core project, we encountered HistoricalOrderSummary.hbm.xml which declared a named query to communicate with a stored procedure for the purposes of retrieving reporting data. In the BasicSample.Data project we find the concrete DAO, HistoricalOrderSummaryDao.cs. This DAO includes the following code to invoke the named query, receive the results, and pass each returned row into the constructor of the value object, HistoricalOrderSummary. The key is the call to SetResultTransformer which informs NHibernate how to translate the results into a new instance of HistoricalOrderSummary. Review the NHibernate documentation to learn about other available options for this translation procedure.

IQuery query = NHibernateSession.GetNamedQuery("GetCustomerOrderHistory")

.SetString("CustomerID", customerId)

.SetResultTransformer(

new NHibernate.Transform.AliasToBeanConstructorResultTransformer(

typeof (HistoricalOrderSummary).GetConstructors()[0]));

Handling the NHibernate Session

At the core of integrating with NHibernate is BasicSample.Data/NHibernateSessionManager.cs. This thread-safe, lazy singleton performs the following duties:

Builds the ISession factory when instantiated for the first time. The class is a singleton because building the session factory is very expensive. In the previous edition of this article, an application setting within web.config declared which assembly contained the HBM files. This is not necessary. Instead, the mapping attribute should be included in the hibernate-configuration. For example, web.config includes the following declaration, within the NHibernate configuration settings, letting NHibernate know where to find the HBMs: <mapping assembly="BasicSample.Core" />. Besides being a cleaner approach than using an application setting, this lends itself better towards managing multiple databases concurrently.
Handles commands sent to the context-specific ISession. Examples include creating/closing the current ISession, registering an IInterceptor (which needs to be done, incidentally, before a transaction is begun), and managing transactions.

Stores and retrieves the context-specific ISession. There are various ways to manage the life-cycle of the ISession; one such approach, called "Open Session in View," is presented shortly. NHibernateSessionManager does not dictate when the ISession needs to be created and destroyed, but it does dictate how the ISession is stored. In the previous edition of this article, CallContext was used as the sole means for storage. This is a very bad idea for ASP.NET applications. The corrected approach leverages HttpContext when it is available and CallContext when it is not. Although this forces you to include a reference to System.Web, this enables seamless portability between WebForms and WinForms. Incidentally, NUnit tests work like a WinForms application, and, thus, benefit from this portability. The following code, pulled from NHibernateSessionManager, demonstrates switching between the appropriate context and is worth showing in its entirety:

Collapse

private ITransaction ThreadTransaction {

    get {

    if (IsInWebContext()) {

    return (ITransaction)HttpContext.Current.

    Items[TRANSACTION_KEY];

    }

    else {

    return (ITransaction)CallContext.GetData(TRANSACTION_KEY);

    }

    }

    set {

    if (IsInWebContext()) {

    HttpContext.Current.Items[TRANSACTION_KEY] = value;

    }

    else {

    CallContext.SetData(TRANSACTION_KEY, value);

    }

    }

    }

    private ISession ThreadSession {

    get {

    if (IsInWebContext()) {

    return (ISession)HttpContext.Current.Items[SESSION_KEY];

    }

    else {

    return (ISession)CallContext.GetData(SESSION_KEY);

    }

    }

    set {

    if (IsInWebContext()) {

    HttpContext.Current.Items[SESSION_KEY] = value;

    }

    else {

    CallContext.SetData(SESSION_KEY, value);

    }

    }

    }

    private bool IsInWebContext() {

    return HttpContext.Current != null;

    }

    private const string TRANSACTION_KEY = "CONTEXT_TRANSACTION";

    private const string SESSION_KEY = "CONTEXT_SESSION";

The basic flow for retrieving a session is as follows:

The client code calls NHibernateSessionManager.Instance.GetSession().
If not already instantiated, this singleton object builds the ISession factory, loading HBM mapping files from the appropriate assembly.
GetSession looks to see if an ISession is already bound to the appropriate context.
If an open NHibernate ISession is not found, then a new one is opened (bound to an optional IInterceptor) and stored back to the appropriate context.
GetSession then returns the context-specific ISession.

This flow, as well as the rest of NHibernateSessionManager, follows that closely described in Hibernate in Action, chapter 8 - Writing Hibernate Applications. We'll next see where the session and/or transaction is begun and committed.

BasicSample.Web for Tying it all Together

As expected, the BasicSample.Web project contains application configuration and ASPX pages. In this sample, the code-behind pages act as controllers, communicating with the domain and data access layers directly. This is not best practice, MVC separation - code-behind pages should be seen as part of the view, pure and simple. But for now, it's simple, and serves well for the demonstration. (The "enterprise" sample application, discussed later, shows a better example of keeping business logic out of the code-behind pages using Model-View-Presenter. Castle MonoRail and Maverick.NET are two other options for separating logic from views, as well. There's even talk of a Microsoft-backed MVC framework in the works. But I digress...)

Here's a closer look at some of the more interesting bits of BasicSample.Web...

Open Session in View

If you want to leverage NHibernate's lazy-loading (which you most certainly will), then the Open-Session-in-View pattern is the way to go. ("Session" in this context is the NHibernate ISession...not the ASP.NET Session object.) Essentially, this pattern suggests that one NHibernate session be opened per HTTP request. Although session management within the ASP.NET page life-cycle is clear in theory, various implementation approaches may be used. The approach I've taken is to create a dedicated IHttpModule to handle the details of the pattern. Aside from centralizing session management responsibilities, this approach provides the additional benefit that we may implement the Open-Session-in-View pattern without putting any session management code into our ASPX pages.

To see how this has been implemented, take a look at BasicSample.Web/App_Code/NHibernateSessionModule.cs. The following section is then included in web.config to activate the IHttpModule:

<httpModules>

<add name="NHibernateSessionModule"

type="BasicSample.Web.NHibernateSessionModule" />

</httpModules>

The IHttpModule opens a transaction at the beginning of a web request, and commits/closes it at the end of the request. The following is an example of modifying the IHttpModule so that an IInterceptor gets bound to the session as well as being contained within a transaction:

public void Init(HttpApplication context) {

context.BeginRequest +=

new EventHandler(InitNHibernateSession);

...

}

private void InitNHibernateSession(object sender, EventArgs e) {

IInterceptor myNHibernateInterceptor = ...

// Bind the interceptor to the session.

// Using open-session-in-view, an interceptor 

// cannot be bound to an already opened session,

// so this must be our very first step.

NHibernateSessionManager.Instance.RegisterInterceptor(

myNHibernateInterceptor);

// Encapsulate the already opened session within a transaction

NHibernateSessionManager.Instance.BeginTransaction();

}

Even if not used, there's very little overhead associated with opening/closing the transaction as NHibernate doesn't actually open a database connection until needed. (With that said, there's room for improvement and a point-of-susceptibility with this approach; see Where to go from here? for areas of further research.) Other strategies that you may want to consider are opening a session not associated with a transaction - hey, it works for eBay - and/or registering an IInterceptor with the NHibernate session. (Using an IInterceptor is great for auditing. See Hibernate in Action, section 8.3.2 - Audit Logging, for more details.)

NHibernate Settings Within web.config

There are two key settings within web.config to optimize NHibernate: hibernate.connection.isolation and hibernate.default_schema. By default, NHibernate uses IsolationLevel.Unspecified as its database isolation level. In other words, NHibernate leaves it up to the ADO.NET provider to determine what the isolation level is by default. If the provider you're using has a default isolation level of Serializable, this is a very strict level of isolation that can be overkill for most application scenarios. A more reasonable setting to start with is ReadCommitted. With this setting, "reading transactions" don't block other transactions from accessing a row. However, an uncommitted "writing transaction" blocks all other transactions from accessing the row. Other provider defaults include (note that they are subject to change by version):

SQL Server 2000 - Read Committed
SQL Server 2005 - Read Committed
Firebird - Read Committed
MySQL's InnoDB - Repeatable Read
PostgreSQL - Read Committed
Oracle - Read Committed

The other optional setting not to be ignored, hibernate.default_schema, is easily overlooked, but can have a significant impact on the querying performance. By default, table names within prepared NHibernate queries - such as those from CreateCriteria - are not fully qualified; e.g., Customers vs. Northwind.dbo.Customers. The crux of the problem is that sp_execsql, the stored procedure used to execute NHibernate queries, does not efficiently optimize queries unless the table names are fully qualified. Although this is a small syntactic difference, it can slow query speeds by as much as an order of magnitude in some cases. Explicitly setting hibernate.default_schema can provide as much as a 33% overall performance gain on data intensive pages. The following is an example of declaring these settings in web.config:

<add key="hibernate.connection.isolation" value="ReadCommitted" />

<add key="hibernate.default_schema" value="Northwind.dbo" />

A Simple List, Add and Update Form

The web project contains a few web pages:

Default.aspx: Provides the navigational homepage for the application.
ListSuppliers.aspx: Fulfills the user story "User may view listing of suppliers and their products." It's a good example of using a custom collection.
ListCustomers.aspx: Fulfills the user story "User may view listing of existing customers." In the enterprise sample, this page loads via Model-View-Presenter (MVP).
EditCustomer.aspx: Fulfills the user stories "User may view details of customer," "User may view a listing of past orders placed by a customer," "User may view a listing of order summaries," and "User may edit customer details." Certainly a lot for one page to take on! The enterprise sample demonstrates how to split up these responsibilities using MVP and handle events coming from the views.
AddCustomer.aspx: Can you guess which user story this one fulfills?

The important thing to note is that the code-behind pages work with a DAO factory to talk to the database; i.e., the code isn't bound to a concrete implementation of a data access object. This makes it much easier to swap DAO implementations and unit test your code without depending on a live database. With everything in place, the following is an example of how easy it is to retrieve all the customers in the database:

IDaoFactory daoFactory = new NHibernateDaoFactory();

ICustomerDao customerDao = daoFactory.GetCustomerDao();

IList<Customer> allCustomers = customerDao.GetAll();

In the above code, a concrete reference to NHibernateDaoFactory is retrieved via new. In production code, as discussed in the Architectural Notes, this reference may (should?) be injected at runtime using an Inversion of Control (IoC) container such as Castle Windsor. The enterprise sample includes an example of using this utility for dependency injection.

While it's acceptable to use the new keyword to create NHiberanteDaoFactory within your code-behind, or controller, your domain objects should never create DAO dependencies directly. Instead, their DAO dependencies should be provided via a public setter or via a constructor. (IoC can help here as well.) As detailed previously, this greatly enhances your ability to unit test with test double DAOs. For example, the following code, found within BasicSample.Tests/Data/CustomerDaoTests.cs, retrieves a customer and gives it its DAO dependency to perform the next action:

IDaoFactory daoFactory = new NHibernateDaoFactory();

ICustomerDao customerDao = daoFactory.GetCustomerDao();

Customer customer = customerDao.GetById(Globals.TestCustomer.ID, false);

// Give the customer its DAO dependency via a public setter

customer.OrderDao = daoFactory.GetOrderDao();

Using this technique, the business layer never needs to depend directly on the data layer. Instead, it depends on interfaces defined within the same layer, as defined in the BasicSample.Core project.

Extending the Basics to an "Enterprise" Solution

What has been discussed thus far has included basic techniques for integrating NHibernate with ASP.NET and unit tests. But what has not been sufficiently demonstrated is the inclusion of these techniques into a scalable, reusable architecture. The "Enterprise" NHibernate Sample demonstrates one such example and is discussed next. As "enterprise" carries many connotations, this article uses this word to describe any real-world, database backed ASP.NET application.

To get the enterprise sample up and running, you'll need to perform the following steps in addition to those described previously in Running the Sample Applications:

Unzip the enterprise sample to the folder of your choice.
Create a new virtual directory within IIS. The alias should be EnterpriseNHibernateSample, and the directory should point to the EnterpriseSample.Web folder that was created after unzipping the application.
Open EnterpriseSample.Web/Config/NorthwindNHibernate.config to modify the database connection string to connect to a Northwind database on Microsoft SQL Server.
Open the following files and change the fully qualified path, which points to EnterpriseSample.Web/Config/NorthwindNHibernate.config, to the corrected path on your machine:
- EnterpriseSample.Web/Web.config
- EnterpriseSample.Web/Config/CastleComponents.config
- EnterpriseSample.Tests/App.config
- EnterpriseSample.Tests/Globals.cs
I don't like having to set this path in this many locations and would like to centralize it to just Web.config and App.config. See Where to go from here? for additional thoughts on how this could be improved.
Open your web browser to http://localhost/EnterpriseNHibernateSample/Default.aspx, and you're off and running!

Real-World Architecture

Although it's best to avoid premature generalization, it's highly beneficial to begin project development with a judiciously planned architecture. A solid architectural foundation is easy to extend, establishes a clean separation of concerns, and provides built-in guidance for developers working with it. There is a fine balance between generalizing too much while still establishing a solid architecture. (I discuss this balance further in a previous post.) Although one shoe does not fit all, the enterprise sample application demonstrates, what I believe to be, a solid architectural framework for medium to large sized ASP.NET projects. The general architectural structure, including direction of concrete and interface dependencies, is shown below.

High-level structure, motivations, and assumptions of this architecture are discussed here.

Beyond the Basics

The enterprise sample extends the basic sample in the following ways:

AbstractNHibernateDao.cs, NHibernateSessionManager.cs, NHibernateSessionModule.cs, and IDao.cs have been placed into their own reusable/extendable project called ProjectBase.Data.
DesignByContract.cs has been placed into their own reusable/extendable project called ProjectBase.Utils.
The can't-debug-NHibernate-without-it log4net has been added and is configured within web.config.
An error logging IHttpModule has been added to the fray.
NHibernateSessionManager.cs has been "upgraded" to support concurrent use of multiple databases. Accordingly, the functionality described within the article Using NHibernate with Multiple Databases has been ported to the sample application. You may certainly revert it back to single database support by using code from the basic sample project.
The design pattern Model-View-Presenter has been employed to separate business logic from ListCustomers.aspx and EditCustomer.aspx. (The version of MVP employed is in line with the definition of Supervising Controller, an MVP specialization.) Accordingly, a new project called EnterpriseSample.Presenters has been created to hold view interfaces and presenters. Associated unit tests have also been added to EnterpriseSample.Tests.
A simple web service, GetCustomer.asmx, has been added which responds with DTOs populated from data retrieved by NHibernate. Please note that this example should not necessarily be considered a best practice example. I am a novice web service designer and am unsure as to what the best practices, with respect to NHibernate integration, really are. See Where to go from here? for an additional note concerning further research needed in this area. A number of related comments have also been included in GetCustomer.cs.
Castle Windsor has been integrated to inject the DAO factory into a Page Controller for pages, user controls and web services. Keep in mind that Castle Windsor may be leveraged much further than this.

Taking a close look at the example code may be daunting at first glance (and for the next couple of glances after that). But once everything's in place, it is powerful, flexible, and is minimally intrusive to the code you're developing.

Where to go from here?

If you were reading a text on an emerging technology, this section would be called "Areas for Further Research." I suppose that would be just as applicable since that's exactly what's described here. There are a few items that could be modified for better flexibility or extended for greater usability. Here are a few ideas to fill any spare time you may have:

The Guidance Automation Toolkit could be leveraged to bundle these best practices into an installable base project.
Few best practices exist for NHibernate integration with web services. Exploring this area and defining at least "better" practices would be very beneficial to the NHibernate community. If you're interested in taking a stab at it, Thomas Erl's Service-Oriented Architecture is a great place to start.
This framework supports transactions which begin and end with the HTTP request. A more ideal scenario would be to use attributes to define when a transaction should be begun. The transaction would then commit at the end of the designated method. Using attributes would avoid a direct dependency on the NHibernateSessionManager class. An example attribute would be [Transaction] and would be placed at the top of a method. Furthermore, if working with multiple databases, the attribute would contain some sort of ID designating which database communications require a transaction, such as [Transaction("Primavera")]. Integration with Castle Project's Automatic Transaction Management facility would be a good place to start.
On a related note, a few developers have complained that using Open-Session-in-View, via NHibernateSessionModule, opens extra, unused transactions for digital assets such as images and CSS files. A discussion, and candidate solutions, may be found in the article's comments. I'm interested in hearing further suggestions for cleanly resolving this occasional problem. (Using attributes to start transactions, as described in the previous point, would also fix this.)
The multiple database implementation passes around each database's config file location to properly identify which ISession belongs with which database. This results in the config file's location being duplicated in both web.config and in the Castle Windsor configuration file. My preference would be to get rid of this duplication, pass a simpler ID string instead, and/or eliminate needing the string to be be passed to the constructor of DAOs altogether.
Using the provided framework, it is not possible to manage a single transaction across two databases located on different servers. Perhaps the System.Transactions namespace could be leveraged to resolve this.
A template Continuous Integration configuration could be created for the enterprise example including CruiseControl.NET, NAnt (or MSBuild), NDepend, FxCop, SandCastle, NDbUnit, NStatic, and FIT/FitNesse.

Please feel free to discuss your ideas for these topics in the comments below, in the NHibernate forums, or in a new CodeProject article! You can also contact me via http://devlicio.us/blogs/billy_mccafferty if you'd be interested in contributing a solution to one of these topics.

Migrating from NHibernate 1.0x to 1.2

If you're migrating from 1.0x to 1.2, you'll most definitely run into a few migration issues. The official overview of the changes to the API may be found within the NHibernate 1.2 Migration Guide. Listed below are a few items that you should pay particular attention to:

Update all references to <hibernate-mapping xmlns="urn:nhibernate-mapping-2.0"> with urn:nhibernate-mapping-2.2. References may be found in HBM and config files.
All classes and collections with 1.2 are now loaded lazily by default. Consequently, if you run your application without modifying the lazy attribute, you'll most likely receive a number of "method x should be virtual." To resolve this, set lazy="false" for each class and collection that you do not want loaded lazily.
Since the use of generics is now natively supported, you'll no longer need Ayende's extremely useful NHibernate.Generics utility. A detailed example of refactoring away from Ayende's NHibernate.Generics may be found at my blog at devlicio.us.

After performing any migration work to NHibernate 1.2, it's good to test the following for each parent/child relationship:

Do updates to a child, via the parent, still work?
Do creations of new children, added to the parent, persist (or not persist) to the database as expected?
Do deletions of existing children from the parent, or by deleting the child directly, work correctly?
Have other CRUD, cascade scenarios been tested?

Summary of NHibernate/ASP.NET Best Practices

The following is a quick summary of the best practices conveyed within the sample application:

Business objects should communicate with data access objects via interfaces; i.e., always depend on abstractions.
Concrete data access objects should implement interfaces defined by the "client", the business logic layer.
Expose data access objects via an abstract factory to assist with testing and to reduce coupling.
Keep NHibernate session management details out of the presentation and business logic layers.
Use unit test categories to easily turn off unit tests that depend on a database connection.
Set hibernate.default_schema within web.config to give NHibernate a great performance boost!

I hope this article has helped with putting best practices into place for leveraging the benefits of ASP.NET, NHibernate, and unit testing. I'm currently having great success with this approach on my own projects, and look forward to hearing your experiences as well. Please let me know if you have any questions or suggestions. And if you want to see what I'm up to at any given moment, you can always follow my latest diatribes at http://devlicio.us/blogs/billy_mccafferty.

Article History

2006.03.12 - Initial posting.
2006.03.13 - Added BasicSample.Tests along with the inclusion of a mock DAO and related discussion above.
2006.03.28 - Clarified the default isolation level and added a plug for Model-View-Presenter.
2006.04.27 - Modified NHibernateSessionManager to store ISession with CallContext instead of HttpContext; updated article text to reflect changes as well. [Author's note: Bad idea!]
2007.04.02 - Published the 1.2^nd edition of this article including compatibility with NHibernate 1.2, an expanded emphasis on test-driven development, and having updated recommendations.
2007.05.01 - Fixed a number of important bugs, gave DomainObject an overhaul, added usage of custom collections, and expanded the MVP examples.

Billy McCafferty

Click here to view Billy McCafferty's online profile.

你可能感兴趣的:(Hibernate)

spring整合hibernate最基础的方式木木ainiks hibernate spring java
1创建文件，可以创建web文件目录2导入jar包，需要导全，我就是jar没导全，后面怎么运行都不对3配置applicationContext.xml<beanid="sessionFactory"
Spring Data JPA kjcoder Spring Data JPA 后端
JPA概述JPA的全称是JavaPersistenceAPI，即Java持久化API，是SUN公司推出的一套基于ORM的规范，内部是由一系列的接口和抽象类构成。JPA规范不干活，真正干活的是依托与它的实现方式(例：hibernate)。搭建环境（需求：保存客户）1.创建maven工程导入坐标org.hibernatehibernate-entitymanager2.需要配置jpa的核心配置文件*位
搭建第一个SpringDataJPA工程码来码去（未来可期） JavaWeb java
第一步：创建maven工程，导入maven坐标使用SpringDataJPA，需要整合Spring与SpringDataJPA，并且需要提供JPA的服务提供者hibernate，所以需要导入spring相关坐标，hibernate坐标，数据库驱动坐标等4.2.4.RELEASE5.0.7.Final1.6.61.2.120.9.1.25.1.6junitjunit4.9testorg.aspect
讨论视频系统架构 Robin-LV MVC JDBC
今天接到一个业务，领导让我搭建一个视频系统架构。架构采用MVC的模式这个大家都知道，技术采用Sping，hibernate3，数据层采用Sping提供的的jdbc模板。我知道要提供一些公共的的类和接口。还有一些封装好的方法。这个架构要考虑现在老系统的数据，等新系统完成要把数据导过去，还要考虑多平台融合的问题。由于我们公司有多套系统，领导想做底层统一以后好管理。现在晕晕的，请高手谈谈如何搭建一个好的
log4jdbc使用介绍 leechiwi log4jdbc
0前言使用java进行数据库操作时最痛苦的莫过于拼接SQL语句。在实际运行时往往需要查看实际生成的SQL语句和实际传入的参数，或许还会有查看SQL执行时间等的需求。无论原生JDBC、dbutils、mybatis还是hibernate，使用log4j等日志框架可以看到生成的SQL，但是占位符和参数总是分开打印的。实在是不太友好。显示如下的效果:select*fromt_userwhereage>?
短视频矩阵源码 fendou--yx898978 抖音账号矩阵系统源码开发 python 开发语言矩阵
矩阵系统源码主要有三种框架：Spring、Struts和Hibernate。Spring框架是一个全栈式的Java应用程序开发框架，提供了IOC容器、AOP、事务管理等功能。Struts框架是一个MVC架构的Web应用程序框架，用于将数据模型、Web应用程序的用户界面和控制器逻辑分离。Hibernate框架是一个面向对象的数据库访问框架，提供了ORM（对象关系映射）机制，允许开发人员使用面向对象的
Java项目中参数校验方法 DebugDiver代码深处潜水员项目相关 java python 开发语言
Java项目中参数校验方法1.参数校验的重要性2.常见的参数校验方法2.1使用`assert`关键字2.2使用`Objects.requireNonNull`2.3使用自定义异常2.4使用`Preconditions`类2.5使用HibernateValidator注解2.6使用Spring框架内的验证2.7使用JSR303/349（BeanValidation）2.8使用ApacheCommon
Java架构师学习路线网络全息测量心得体会
(1)第一步：研究spring,hibernate。通过研究jeecms开源框架。也同时学习css,html,javascript,jquery.以前都学习过，不过没有系统学习过，现在必须系统学习。同时看cms相关的论文。然后，改造jeecms能够改为自己的一个开源框架，以后开发cms系统都用我自己开发的框架，作为第一阶段的成果。(2)第二步：学习开源工作流引擎Activiti5，jbpm4.4以
SpringBoot操作GBase8s数据库示例迷你世界～爱丽丝
SpringBoot+Hibernate(Jpa)操作GBase8s数据库示例GBase8s数据库是国产事务型数据库，目前已在各领域广泛应用，本篇使用当下主流的J2EE框架Springboot集成Hibernate（Jpa），对GBasse8S数据库CRUD操作进行讲解。1.技术点JPA是JAVA标准持久化API，是SUN公司推出的一套基于ORM的规范；Hibernate是对JPA（ORM规范）的
chapter01 Java语言概述知识点Note 月下绯烟 Java java 开发语言
JavaSEJavaEEJavaME大数据Java基础常用技术栈mysqlJDBCSSMspring+springmvc+mybatisLinuxnacosHadoopFlinkJAVAEE消息队列rabbitMQdocker数据库redisspringbootspringcloudsshstruts+spring+hibernate过时技术栈很少用JAVA虚拟机jvm分布式微服务高并发常见dos
SpringBoot学习（5）Spring boot Jpa使用星河漫漫l springboot 开发语言运维开发学习
SpringBootJpa介绍首先了解Jpa是什么？Jpa(JavaPersistenceAPI)是Sun官方提出的Java持久化规范。它为Java开发人员提供了一种对象/关联映射工具来管理Java应用中的关系数据。它的出现主要是为了简化现有的持久化开发工作和整合ORM技术，结束现在Hibernate，TopLink，JDO等ORM框架各自为营的局面。值得注意的是，Jpa是在充分吸收了现有Hibe
springboot日常开发参数校验注解听忆. 日常开发 mysql java 数据库
springboot日常开发参数校验注解1.常用的参数校验注解2.使用示例3.在Controller中使用4.全局异常处理5.自定义校验注解边走、边悟迟早会好在SpringBoot的日常开发中，常常使用参数校验注解来保证传入的数据符合业务逻辑或预期格式。SpringBoot内置了对JSR-303和JSR-380标准的支持，主要依赖javax.validation和HibernateValidato
mysql报错1785_MYSQL Statement violates GTID consistency: Updates to non-transactional tables can only ... 张观鱼 mysql报错1785
[2019-04-2110:17:20][ERROR][org.hibernate.engine.jdbc.spi.SqlExceptionHelper:144]StatementviolatesGTIDconsistency:Updatestonon-transactionaltablescanonlybedoneineitherautocommittedstatementsorsingle-s
SpringBoot2快速入门05--jpa 老鼠AI大米_Java全栈
本节我们学习使用Jpa，jpa其实是一个规范，在出来之前，都是使用hibernate，hibernate可以使程序员以面向对象的方式操作数据库，我还是喜欢nativesql。先导入相关包，如下：compile('org.springframework.boot:spring-boot-starter-data-jpa')compile('mysql:mysql-connector-java')配置
JPA简介与实战是Guava不是瓜娃 SSM jpa
一、什么是JPAJPA：JavaPersistenceAPI，Java持久层API。是JDK5.0注解或XML描述对象－关系表的映射关系，并将运行期的实体对象持久化到数据库中。类似于JDBC，JPA是一组规范（接口），使应用程序以统一方式访问持久层。具体的实现：HibernateToplink其他ORM框架JPA和Hibernate的关系JPA是规范：JPA本质上就是一种ORM规范，不是ORM框架
Hibernate Session在项目中的创建方式 jingde528 Hibernate java hibernate 前端 java
创建一个单例模式工具类，再通过在Hibernate配置文件中开启Session的线程管理模式的方法单例模式工具类packagetest.hibernate.spring.dao;importorg.hibernate.Session;importorg.hibernate.SessionFactory;importorg.hibernate.boot.MetadataSources;importo
Hibernate的检索策略(lazy、fetch、batch-size) jingde528 Hibernate hibernate batch java
Hibernate的检索策略包括立即检索和延迟检索，可以在配置文件中通过对lazy、fetch、batch-size属性的设置来进行控制。一对多、多对多、多对一和一对一关系下的不同检索策略将影响对数据库访问的效率。检索策略立即检索，立即加载检索方法指定的对象延迟检索，延迟加载检索方法指定的对象，在使用具体属性值时，才进行加载(这个时候会执行查询语句)检索策略使用场景如果加载对象是为了访问他的属性，
JAVA Web学习(22)___第16章Hibernate技术岁月静好浅笑安然
第16章Hibernate技术16.1初识Hibernate16.1.1理解ORM原理16.1.2Hibernate简介Hibernate是一款免费开源的持久层框架，它对JDBC进行了轻量级的对象封装，将对象与数据库表建立了映射关系，使Java编程人员可以随心所欲地使用面向对象的编程思想操作数据库。Hibernate具有简单易用、灵活性强、扩展性强等特点，大大提高了程序的开发效率。使用传统的JDB
Java编程开发新手学习：数组方法的应用猜字母游戏 Java小辰
Java是一种可以撰写跨平台应用软件的面向对象的程序设计语言。Java技术具有卓越的通用性、高效性、平台移植性和安全性，广泛应用于PC、数据中心、游戏控制台、科学超级计算机、移动电话和互联网，同时拥有全球最大的开发者专业社群。给你学习路线：html-css-js-jq-javase-数据库-jsp-servlet-Struts2-hibernate-mybatis-spring4-springmv
Spring Data：JPA与Querydsl 光图强 java
JPAJPA是java的一个规范，用于在java对象和数据库之间保存数据，充当面向对象领域模型和数据库之间的桥梁。它使用Hibernate、TopLink、IBatis等ORM框架实现持久性规范。SpringDataSpringData是Spring的一个子项目，用于简化数据库访问，支持NoSql数据和关系数据库。支持的NoSql数据库包括：Mongodb、redis、Hbase、Neo4j。Sp
@Autowired获取配置文件中被注入实例的两种方式 weixin_30719711 java
一、说明二、那么在JavaBean中如何通过@Autowired获取该实例呢？有两种方式：1.直接获取@RunWith(SpringJUnit4ClassRunner.class)@ContextConfiguration("classpath:applicationContext_test.xml")publicclassMyTest1{@AutowiredprivateHibernateTem
Java Hibernate深度解析：11步精通ORM框架的艺术与安全墨瑾轩 Java乐园 java hibernate 安全
关注墨瑾轩，带你探索编程的奥秘！超萌技术攻略，轻松晋级编程高手技术宝库已备好，就等你来挖掘订阅墨瑾轩，智趣学习不孤单即刻启航，编程之旅更有趣第1章：引言：JPA与Hibernate的邂逅1.1什么是JPA？Hey，小伙伴们，欢迎来到JPA的奇妙世界！JPA，全称JavaPersistenceAPI，是一个让Java程序和数据库愉快玩耍的桥梁。想象一下，你有一个装满玩具的盒子，JPA就是帮你把玩具（
手写Spring框架，加深对Spring工作机制的理解！ Java提升营
在我们的日常工作中，经常会用到Spring、SpringBoot、SpringCloud、Struts、Mybatis、Hibernate等开源框架，有了这些框架的诞生，平时的开发工作量也是变得越来越轻松，我们用SpringBoot分分钟可以新建一个Web项目。记得自己刚开始工作的时候还是在用Servlet写Web项目，自己写数据库连接池，用原生JDBC操作数据库，好了不发散了。回到这篇文章的主题
现在程序员这么多，我学习java这块应该学到什么程度才能不被淘汰呢？渡你眉间山河
一、夯实基础JavaSE这是基础，一定要好好学习！Java语法，面向对象（包括类、对象、方法、继承、封装、抽象、多态、消息解析等），常见API，数据结构，集合框架，设计模式（包括创建型、结构型、行为型），多线程和并发，I/O流，Stream，网络编程。JavaEEJavaEE是在JavaSE的基础上构建的，JavaEE容器，Web容器，常用框架（包括Struts2、Hibernate、Mybati
SpringBoot JPA Puny丶微芒
定义JPA是JavaPersistenceAPI的简称，中文名Java持久层API，是JDK5.0注解或XML描述对象－关系表的映射关系，并将运行期的实体对象持久化到数据库中。JPA的总体思想和现有Hibernate、TopLink、JDO等ORM框架大体一致。总的来说，JPA包括以下3方面的技术：1.ORM映射元数据JPA支持XML和JDK注解两种元数据的形式，元数据描述对象和表之间的映射关系，
什么是hql以及hql和sql的区别 m0_48680499
一、hql的定义Hibernate查询语言（HQL）是一种面向对象的查询语言，类似于SQL，但不是去对表和列进行操作，而是面向对象和它们的属性。二、HQL1.HQL里面的类名和属性名区分大小写，但关键字不区分大小写2.?从下标0开始计算位置3.HQL支持:命名参数4.HQL是面向对象的查询语言三、SQL1.SQL里面的表名和列名不区分大小写2.?从顺序1开始计算位置3.SQL不支持:命名参数4.S
关于springboot持久层框架mybatis+jpa组合使用小码农吗日常栏目 java mybatis spring boot mysql
一、简介JPA和MyBatis各有各的好处，混合食用效果更佳。(hibernate是面向对象的，而MyBatis是面向关系的)个人总结（总结自己的理解）1.表关联较多的项目，优先使用mybatis2.持续维护开发迭代较快的项目建议使用mybatis，因为一般这种项目需要变化很灵活，对sql的灵活修改要求较高3.对于传统项目或者关系模型较为清晰稳定的项目，建议JPA（比如DDD设计中的领域层）4.目
java批量导入和批量删除_Hibernate批处理操作优化 (批量插入、更新与删除) 林落年 java批量导入和批量删除
问题描述我开发的网站加了个新功能：需要在线上处理表数据的批量合并和更新，昨天下午发布上线，执行该功能后，服务器的load突然增高，变化曲线异常，SA教育了我一番，让我尽快处理，将CPU负载降低。工作所需，我经常要写些程序批量处理数据，每次执行几十万数据处理的时候，我机子的CPU都会飙高，而且数据处理速度会越来越慢。比如第一个1W条要5分钟，第二个1W条就要10分钟，要干其他事情的时候机子也卡的不行
mysql jdbc批量更新_Hibernate+JDBC实现批量插入、更新及删除的方法详解 weixin_39524147 mysql jdbc批量更新
本文实例讲述了HibernateJDBC实现批量插入、更新及删除的方法。分享给大家供大家参考，具体如下：一、批量插入(两种方式)1.通过Hibernate缓存如果这样写代码进行批量插入(初始设想)：packagecom.anlw.util;importorg.hibernate.Session;importorg.hibernate.SessionFactory;importorg.hiberna
Python之路：Django进阶篇中國颜值的半壁江山 django django
Modeldjango为使用一种新的方式，即：关系对象映射（ObjectRelationalMapping，简称ORM）。PHP：activerecordJava：HibernateC#：EntityFrameworkdjango中遵循CodeFrist的原则，即：根据代码中定义的类来自动生成数据库表。一、创建表1、基本结构fromdjango.dbimportmodels#Createyourm
rust的指针作为函数返回值是直接传递，还是先销毁后创建？ wudixiaotie 返回值
这是我自己想到的问题，结果去知呼提问，还没等别人回答，我自己就想到方法实验了。。 fn main() { let mut a = 34; println!("a's addr:{:p}", &a); let p = &mut a; println!("p's addr:{:p}", &a
java编程思想 -- 数据的初始化百合不是茶 java 数据的初始化
1.使用构造器确保数据初始化 /* *在ReckInitDemo类中创建Reck的对象 */ public class ReckInitDemo { public static void main(String[] args) { //创建Reck对象 new Reck(); } }
[航天与宇宙]为什么发射和回收航天器有档期 comsci
地球的大气层中有一个时空屏蔽层,这个层次会不定时的出现,如果该时空屏蔽层出现,那么将导致外层空间进入的任何物体被摧毁,而从地面发射到太空的飞船也将被摧毁... 所以,航天发射和飞船回收都需要等待这个时空屏蔽层消失之后,再进行 &
linux下批量替换文件内容商人shang linux 替换
1、网络上现成的资料　　格式: sed -i "s/查找字段/替换字段/g" `grep 查找字段 -rl 路径` 　　linux sed 批量替换多个文件中的字符串　　sed -i "s/oldstring/newstring/g" `grep oldstring -rl yourdir` 　　例如：替换/home下所有文件中的www.admi
网页在线天气预报 oloz 天气预报
网页在线调用天气预报 <%@ page language="java" contentType="text/html; charset=utf-8" pageEncoding="utf-8"%> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transit
SpringMVC和Struts2比较杨白白 springMVC
1. 入口 spring mvc的入口是servlet，而struts2是filter（这里要指出，filter和servlet是不同的。以前认为filter是servlet的一种特殊），这样就导致了二者的机制不同，这里就牵涉到servlet和filter的区别了。参见：http://blog.csdn.net/zs15932616453/article/details/8832343 2
refuse copy, lazy girl! 小桔子 copy
妹妹坐船头啊啊啊啊！都打算一点点琢磨呢。文字编辑也写了基本功能了。。今天查资料，结果查到了人家写得完完整整的。我清楚的认识到： 1.那是我自己觉得写不出的高度 2.如果直接拿来用，很快就能解决问题 3.然后就是抄咩~~ 4.肿么可以这样子，都不想写了今儿个，留着作参考吧！拒绝大抄特抄，慢慢一点点写！
apache与php整合 aichenglong php apache web
一 apache web服务器 1 apeche web服务器的安装 1)下载Apache web服务器 2)配置域名(如果需要使用要在DNS上注册) 3)测试安装访问http://localhost/验证是否安装成功 2 apache管理 1)service.msc进行图形化管理 2)命令管理，配
Maven常用内置变量 AILIKES maven
Built-in properties ${basedir} represents the directory containing pom.xml ${version} equivalent to ${project.version} (deprecated: ${pom.version}) Pom/Project properties Al
java的类和对象百合不是茶 JAVA面向对象类对象
java中的类： java是面向对象的语言，解决问题的核心就是将问题看成是一个类，使用类来解决 java使用 class 类名来创建类，在Java中类名要求和构造方法，Java的文件名是一样的创建一个A类： class A{ } java中的类：将某两个事物有联系的属性包装在一个类中，再通
JS控制页面输入框为只读 bijian1013 JavaScript
在WEB应用开发当中，增、删除、改、查功能必不可少，为了减少以后维护的工作量，我们一般都只做一份页面，通过传入的参数控制其是新增、修改或者查看。而修改时需将待修改的信息从后台取到并显示出来，实际上就是查看的过程，唯一的区别是修改时，页面上所有的信息能修改，而查看页面上的信息不能修改。因此完全可以将其合并，但通过前端JS将查看页面的所有信息控制为只读，在信息量非常大时，就比较麻烦。
AngularJS与服务器交互 bijian1013 JavaScript AngularJS $http
对于AJAX应用（使用XMLHttpRequests）来说，向服务器发起请求的传统方式是：获取一个XMLHttpRequest对象的引用、发起请求、读取响应、检查状态码，最后处理服务端的响应。整个过程示例如下： var xmlhttp = new XMLHttpRequest(); xmlhttp.onreadystatechange
[Maven学习笔记八]Maven常用插件应用 bit1129 maven
常用插件及其用法位于：http://maven.apache.org/plugins/ 1. Jetty server plugin 2. Dependency copy plugin 3. Surefire Test plugin 4. Uber jar plugin 1. Jetty Pl
【Hive六】Hive用户自定义函数(UDF) bit1129 自定义函数
1. 什么是Hive UDF Hive是基于Hadoop中的MapReduce，提供HQL查询的数据仓库。Hive是一个很开放的系统，很多内容都支持用户定制，包括：文件格式：Text File，Sequence File 内存中的数据格式： Java Integer/String, Hadoop IntWritable/Text 用户提供的 map/reduce 脚本：不管什么
杀掉nginx进程后丢失nginx.pid，如何重新启动nginx ronin47 nginx 重启 pid丢失
nginx进程被意外关闭，使用nginx -s reload重启时报如下错误：nginx: [error] open() “/var/run/nginx.pid” failed (2: No such file or directory)这是因为nginx进程被杀死后pid丢失了，下一次再开启nginx -s reload时无法启动解决办法：nginx -s reload 只是用来告诉运行中的ng
UI设计中我们为什么需要设计动效 brotherlamp UI ui教程 ui视频 ui资料 ui自学
随着国际大品牌苹果和谷歌的引领，最近越来越多的国内公司开始关注动效设计了，越来越多的团队已经意识到动效在产品用户体验中的重要性了，更多的UI设计师们也开始投身动效设计领域。但是说到底，我们到底为什么需要动效设计？或者说我们到底需要什么样的动效？做动效设计也有段时间了，于是尝试用一些案例，从产品本身出发来说说我所思考的动效设计。一、加强体验舒适度嗯，就是让用户更加爽更加爽的用你的产品。
Spring中JdbcDaoSupport的DataSource注入问题 bylijinnan java spring
参考以下两篇文章： http://www.mkyong.com/spring/spring-jdbctemplate-jdbcdaosupport-examples/ http://stackoverflow.com/questions/4762229/spring-ldap-invoking-setter-methods-in-beans-configuration Sprin
数据库连接池的工作原理 chicony 数据库连接池
随着信息技术的高速发展与广泛应用，数据库技术在信息技术领域中的位置越来越重要，尤其是网络应用和电子商务的迅速发展，都需要数据库技术支持动态Web站点的运行，而传统的开发模式是：首先在主程序（如Servlet、Beans）中建立数据库连接；然后进行SQL操作，对数据库中的对象进行查询、修改和删除等操作；最后断开数据库连接。使用这种开发模式，对
java 关键字 CrazyMizzz java
关键字是事先定义的，有特别意义的标识符，有时又叫保留字。对于保留字，用户只能按照系统规定的方式使用，不能自行定义。 Java中的关键字按功能主要可以分为以下几类：（1）访问修饰符 public,private,protected p
Hive中的排序语法 daizj 排序 hive order by DISTRIBUTE BY sort by
Hive中的排序语法 2014.06.22 ORDER BY hive中的ORDER BY语句和关系数据库中的sql语法相似。他会对查询结果做全局排序，这意味着所有的数据会传送到一个Reduce任务上，这样会导致在大数量的情况下，花费大量时间。与数据库中 ORDER BY 的区别在于在hive.mapred.mode = strict模式下，必须指定 limit 否则执行会报错。
单态设计模式 dcj3sjt126com 设计模式
单例模式（Singleton）用于为一个类生成一个唯一的对象。最常用的地方是数据库连接。使用单例模式生成一个对象后，该对象可以被其它众多对象所使用。 <?phpclass Example{ // 保存类实例在此属性中 private static&
svn locked dcj3sjt126com Lock
post-commit hook failed (exit code 1) with output: svn: E155004: Working copy 'D:\xx\xxx' locked svn: E200031: sqlite: attempt to write a readonly database svn: E200031: sqlite: attempt to write a
ARM寄存器学习 e200702084 数据结构 C++c C#F#
无论是学习哪一种处理器，首先需要明确的就是这种处理器的寄存器以及工作模式。 ARM有37个寄存器，其中31个通用寄存器，6个状态寄存器。 1、不分组寄存器（R0-R7）不分组也就是说说，在所有的处理器模式下指的都时同一物理寄存器。在异常中断造成处理器模式切换时，由于不同的处理器模式使用一个名字相同的物理寄存器，就是
常用编码资料 gengzg 编码
List<UserInfo> list=GetUserS.GetUserList(11); String json=JSON.toJSONString(list); HashMap<Object,Object> hs=new HashMap<Object, Object>(); for(int i=0;i<10;i++) {
进程 vs. 线程 hongtoushizi 线程 linux 进程
我们介绍了多进程和多线程，这是实现多任务最常用的两种方式。现在，我们来讨论一下这两种方式的优缺点。首先，要实现多任务，通常我们会设计Master-Worker模式，Master负责分配任务，Worker负责执行任务，因此，多任务环境下，通常是一个Master，多个Worker。如果用多进程实现Master-Worker，主进程就是Master，其他进程就是Worker。如果用多线程实现
Linux定时Job：crontab -e 与 /etc/crontab 的区别 Josh_Persistence linux crontab
一、linux中的crotab中的指定的时间只有5个部分：* * * * * 分别表示：分钟，小时，日，月，星期，具体说来：第一段代表分钟 0—59 第二段代表小时 0—23 第三段代表日期 1—31 第四段代表月份 1—12 第五段代表星期几，0代表星期日 0—6 如： */1 * * * * 每分钟执行一次。 *
KMP算法详解 hm4123660 数据结构 C++算法字符串 KMP
字符串模式匹配我们相信大家都有遇过，然而我们也习惯用简单匹配法（即Brute-Force算法)，其基本思路就是一个个逐一对比下去，这也是我们大家熟知的方法，然而这种算法的效率并不高，但利于理解。假设主串s="ababcabcacbab",模式串为t="
枚举类型的单例模式 zhb8015 单例模式
E.编写一个包含单个元素的枚举类型[极推荐]。代码如下： public enum MaYun {himself; //定义一个枚举的元素，就代表MaYun的一个实例private String anotherField;MaYun() {//MaYun诞生要做的事情//这个方法也可以去掉。将构造时候需要做的事情放在instance赋值的时候：/** himself = MaYun() {*
Kafka+Storm+HDFS ssydxa219 storm
cd /myhome/usr/stormbin/storm nimbus &bin/storm supervisor &bin/storm ui &Kafka+Storm+HDFS整合实践kafka_2.9.2-0.8.1.1.tgzapache-storm-0.9.2-incubating.tar.gzKafka安装配置我们使用3台机器搭建Kafk
Java获取本地服务器的IP 中华好儿孙 java Web 获取服务器ip地址
System.out.println("getRequestURL:"+request.getRequestURL()); System.out.println("getLocalAddr:"+request.getLocalAddr()); System.out.println("getLocalPort:&quo