Community Blogs

First of all I'd like to remark that I'm not following PoEA Repository pattern. I just like this name! =) Repository and Dao interfaces still remains hot topic today. While developing my last ASP.NET MVC application I've created my own interface, which I think suits best for me. public interface IRepository { IQueryable<T> CreateQuery<T>() where T : class; void Execute(Action<IPersister> action); } public interface IPersister { void Delete<T>(); void SaveOrUpdate<T>(); } The most thing I like here is that I can hide transaction management in execute method implementation by wrapping Execute method delegate in "using transaction block" with try. Sketch implementation of Execute method. void...

In an earlier post I talked about writing a Transaction attribute for MVC using NHibernate (though it isn’t really NHibernate specific).  The basic idea is that when an action marked with [Transaction] is executing (OnActionExecuting) you begin a transaction, and some time later (I use OnActionExecuted, but Kazi Manzur Rashid makes a good argument for OnResultExecuted ) you commit that transaction if there was no error, or rollback if there was an error.   With that in mind, the implementation details aren’t really important because my motivation in this post is to make every action transactional by default.  Most of the actions on any real site will require retrieving, updating, saving or removing data so as a best practice I...

        Telerik recently released their Extensions for ASP.NET MVC which include several great controls, the most immediately useful of which is their Grid control.  In the simple (and probably most common) cases the grid works by passing taking an enumerable list of objects (let’s say Northwind Orders for this example) and rendering this out as a table based on a fluent configuration.  The benefit of passing in an enumerable list is that Telerik’s Grid will use its data engine and dynamically page, sort and filter your data on the server (aka: at the database), which is a huge win.  However, by allowing the Grid to handle your actual database call you lose control of transactional support and you...

I wrote a post about a month ago about using xVal with NHibernate Validator 1.2 which solved a problem I was having upgrading the xVal ‘in-the-box’ provider to work with a newer version of NHibernate Validator . There was a caveat that my solution only worked for ValidatorMode.UseAttribute and I wouldn’t catch XML or Loquacious (or other?) validation.  This seemed to work OK, but Fabio Maulo wrote a comment to that post saying NHV has metadata which should be the same no matter which validation mode was used. So I decided to investigate how I could get the metadata without resorting to the NHibernate.Validator.Mappings validationMode specific engines (I was using ReflectionClassMapping, but there are others like XmlClassMapping). I think...

Get it here . Intersting to note, the API documentation is now available in CHM format. Read More...

While I was planning to write about the same topic and have the draft ready in my Windows Live Writer waiting to complete, I found an interesting question in StackOVerflow and couldn’t just resist to answer: ORM/Persistence layer Advice The question starts with: I'm starting a new project and I'm looking around for either a very good ORM or for a non-SQL-based persistence layer. Then follows up with a REALLY GOOD summary of what he believes about each known ORM he knew out of his own findings and search. I advice you to go read it. However, all this investigation didn’t get him to a single choice answer. And I can’t blame him. This is one fo the questions that will remain for so long without a single answer, or maybe having the popular...

So I’m building a product with NHibernate and possibly another ORM. The main focus of the app is a ASP.NET MVC 2.0 web application . So I, obviously, want the built in validation client-side in JavaScript and server side. By default, the MVC stuff uses the System.ComponentModel.DataAnnotations attributes to validate properties on your domain. What I REALLY wanted was to use the Data Annotations with Fluent NHibernate for my DB mapping files. This presents a problem, right? WRONG! Because Fluent NHibernate is so extensible, I can easily create a convention to use the Attributes. Then all I have to do is add the convention to my Fluent NHibernate AutoMapper instance and the properties with the attributes are just taken care of. Isn’t that neat...

I recently setup my first continuous integration build server using JetBrains’ TeamCity product, and it couldn’t have been much simpler. However I kept running into an issue with my test projects whenever I was using NHibernate or SQLite (very useful or regression tests against an in-memory database). The Problem Everything would run correctly locally using MSTest, but when TeamCity ran the tests I would get the following error: Unable to load type 'NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle' during configuration of proxy factory class. Possible causes are: - The NHibernate.Bytecode provider assembly was not deployed. - The typeName used to initialize the 'proxyfactory.factory_class' property of...

I’ve recently switched from the Enterprise Library Validation Application Block to using NHibernate Validators. If you are not familiar with the NHibernate Validator project, they are part of the NHibernate Contrib project and offer Validation constraints, and validation runner, and tight integration with NHibernate (especially great if you use NHibernate to generate your DB). One of the main reasons for my switch was integration with xVal (which EntLib Validation’s implementation prevents), and also to get some advanced but common validators like Email, Size, NotNullNotEmpty. Anyway, I would recommend that you look at NHibernate Validator if you use NHibernate and are looking for a validation framework.  However, this post is about writing...

With the arrival of the LINQ provider for NHibernate, NHibernate now supports ADO.NET Data Services. There are some restrictions, however: Relations must be entities or simple collections of entities (Entity, IList, IList<T>), not sets (ISet<T>, HashSet<T>) or maps (IDictionary, IDictionary<K, V>, HashTable); The ID property must be called either "ID", or end with "ID", for example, CustomerID; The ID property must have a public setter as well as a public getter; The ID property must be of a base type, such as int or string; The collections to expose must be properties of type IQueryable<T> or IOrderedQueryable<T>. Here is an example: public class Customer { public virtual Int32 ID { get;...