This is the second post of a serie started with this post about a MonoRail and ActiveRecord tutorial.
Let’s start developing our sample application. The first thing we need to do is to create a .NET project configured for using the CastleProject stuff. You can go in two ways:
- Create a Visual Studio project with the MonoRail project wizard.
The wizard will create for you the MonoRail project structure, generate the configuration elements in the web.config file and add all the necessary references to the project.
You will be prompted to choose a view engine (NVelocity, Brail or ASP .Net Web Forms), if to enable the Windsor inversion of control, and if you wish to create a test project for TDD (Test Driven Development).
For the purpose of this tutorial choose NVelocity, not enable Windsor and create the TDD test project. You can look at the procedure here. - If you are using another IDE than Visual Studio, or if you want to manually configure the environment, you can look at the manual procedure in the same link of the first point.
The references that will be added are:
- Castle.MonoRail.Framework.dll: The MonoRail framework, that implements for the project the MVC Pattern
- Castle.MonoRail.Framework.Views.NVelocity.dll: The view engine we have chosen
- Castle.Components.Binder.dll: The binder implementation
- Castle.Components.Common.EmailSender.dll: The email service contracts
- Castle.Components.Common.EmailSender.SmtpEmailSender.dll: The email service implementation
- Castle.Core.dll: Core functionalities shared by Castle Projects
- NVelocity.dll: The template engine
The following project structure is created (this is a convention, you could go for an alternative structure):
The MVC Pattern implemented by MonoRail is composed of 3 kinds of objects: the models, the views and the controllers.
- The models are the .NET classes that are related to the Domain Model of the enterprise solution we need to develop. Typically these classes manage data that must be persisted on a database, and give the business logic of the application. So in the models we will implement the data access layer (for this tutorial with ActiveRecord) and the business logic layer. The models classes are typically placed in the models directory.
- The views contains the user interface layer of the application, and they render the contents to the user. For web applications are tipically html pages with data binded to them. This is obtained in MonoRail by a view engine like NVelocity and by the outstanding binding libraries. The views have a .vm extensions and, for convention, should be placed in the views directory.
- The controllers are the way in the MVC Pattern processes and events are managed. As a convention in MonoRail the controllers (that are - like models - .NET classes) are placed in the controllers folder.
In the MVC the control flow generally works like this:
- The user interacts with the user interface (user press a button to edit in the application an existing album)
- A controller handles the event sinked from the interaction of the user, and accesses the model. Some contents may be presented in the user interface (the album attributes actually stored in the database are displayed from the view at the user interface)
- the view gets its own data from the model. The view communicates directly with the model, not via the controller
- the cycle may be restarted from another action performed by the user (the user may change the artist of the album)
In our application we will use NVelocity as the view engine. NVelocity is a template engine that was ported from the Jakarta Velocity Project developed from the Java community. In the MVC of MonoRail it is used in the views to clearly separate the application logic from the web design. This way a developer and a designer can work in the same project without interfering each other. For an introduction to NVelocity you can look here (is about Velocity but everything is perfectly appliabel to NVelocity).
Note that you are not forced to use NVelocity but you can choose other template engines like Brail or even Web Forms. NVelocity is based on the Velocity language, Brail on the Boo language (Python syntax), and Web Forms of course on the .NET language you prefer. From these tre chooses I like NVelocity because it is simple and it is not compiled, and this is very nice because I can repeatitly change the user interface design without stopping the application’s execution and recompile. Here you will find a very nice comparison of these template engines.
Now the project is configured for using MonoRail: you have to add the ActiveRecord configuration. Remember that you could of course use the two frameworks separately, this meaning that:
- You could use the ActiveRecord framework as the DAL (Data Access Layer) strategy in your classic ASP .NET Web Forms or .NET Windows forms application
- You could use MonoRail for implementing your solution (in place of ASP .NET Web Forms) and still go with ADO .NET or other DAL strategies (like NHibernate without ActiveRecord) you may like more
Add to your project the following references:
- Castle.ActiveRecord.dll: the Active Record pattern implementation from CastleProject
- Castle.DynamicProxy.dll: the Dynamic Proxy pattern implementation from CastleProject
- Iesi.Collections.dll: ISet collections used by NHibernate
- log4net.dll: a very nice and powerfull logging engine for .NET (ported from the log4j project for Java)
- NHibernate.dll: the fantastic and extremely powerfull OS ORM tool (ported from the Hibernate project for Java)
Now you can open the web.config file. You have to add to it the ActiveRecord configuration. This is a sample about how to do this (at this point you need to add only the activerecord section: the other sections, monorail and the http handlers and modules, should be already have been added to the web.config from the previous steps):
<configuration> <configSections> <section name="monorail" type="Castle.MonoRail.Framework.Configuration.MonoRailSectionHandler, Castle.MonoRail.Framework" /> <section name="activerecord" type="Castle.ActiveRecord.Framework.Config.ActiveRecordSectionHandler, Castle.ActiveRecord" /> </configSections> <!-- ActiveRecord configuration: comment out the config you need for your db (SLQ Server, PostgreSQL, MySQL). You can find more configuration at castleproject web site --> <!-- SQL Server <activerecord isWeb="true"> <config> <add key="hibernate.connection.driver_class" value="NHibernate.Driver.SqlClientDriver" /> <add key="hibernate.dialect" value="NHibernate.Dialect.MsSql2000Dialect" /> <add key="hibernate.connection.provider" value="NHibernate.Connection.DriverConnectionProvider" /> <add key="hibernate.connection.connection_string" value="Data Source=localhost;Initial Catalog=castle;Integrated Security=SSPI" /> </config> </activerecord> --> <!--PostgreSQL--> <activerecord isWeb="true"> <config> <add key="hibernate.connection.driver_class" value="NHibernate.Driver.NpgsqlDriver" /> <add key="hibernate.dialect" value="NHibernate.Dialect.PostgreSQLDialect" /> <add key="hibernate.connection.provider" value="NHibernate.Connection.DriverConnectionProvider" /> <add key="hibernate.connection.connection_string" value="Server=localhost;Database=castle;User ID=castle;Password=castle;" /> </config> </activerecord> <!--MySQL <activerecord isWeb="true"> <config> <add key="hibernate.connection.driver_class" value="NHibernate.Driver.MySqlDataDriver" /> <add key="hibernate.dialect" value="NHibernate.Dialect.MySQLDialect" /> <add key="hibernate.connection.provider" value="NHibernate.Connection.DriverConnectionProvider" /> <add key="hibernate.connection.connection_string" value="Database=castle;Data Source=asadev;User Id=castle;Password=castle" /> </config> </activerecord> --> <!-- For more on monoRail configuration see http://www.castleproject.org/monorail/documentation/v1rc2/index.html --> <monorail smtpHost="yoursmtphost" useWindsorIntegration="false"> <controllers> <assembly>PaoloSampleApplication</assembly> </controllers> <viewEngine viewPathRoot="Views" customEngine="Castle.MonoRail.Framework.Views.NVelocity.NVelocityViewEngine, Castle.MonoRail.Framework.Views.NVelocity" /> </monorail> <system.web> <httpHandlers> <add verb="*" path="*.rails" type="Castle.MonoRail.Framework.MonoRailHttpHandlerFactory, Castle.MonoRail.Framework" /> <!-- block direct user access to template files --> <add verb="*" path="*.vm" type="System.Web.HttpForbiddenHandler" /> <add verb="*" path="*.boo" type="System.Web.HttpForbiddenHandler" /> <add verb="*" path="*.st" type="System.Web.HttpForbiddenHandler" /> </httpHandlers> <httpModules> <add name="monorail" type="Castle.MonoRail.Framework.EngineContextModule, Castle.MonoRail.Framework" /> </httpModules> </system.web> </configuration>
Note that I am using Postgres as RDBMS. If you want to use SQL Server, or MySQL (I have successfully tested with all these RDBMS this tutorial) just comment the active record configuration for Postgres and comment out the one for your RDBMS. You can use any RDBMS supported by NHibernate, more configuration sample sections can be found here.
We can now start adding our domain model classes. As we have seen we have to write the code for the following entities: Album, Artist, Genre and Support. As we have also a many-to-many relationships (Album-Genre) with an attribute on the association table (MainGenre), we need to create a class that map this association for managing this attribute. So we need still another class: AlbumGenre.
Writing the domain model classes will be the topic of the Part 3 of this tutorial.











very interesting, but I don’t agree with you
Idetrorce