Showing posts with label castle. Show all posts
Showing posts with label castle. Show all posts

Tuesday, May 13, 2008

Registering MonoRail Extensions Programatically

Hammett inspired me to switch from XML configuration to programmatic configuration of MonoRail with this blog post. But he didn't discuss how to configure MonoRail extensions. I searched around through the source and came up with this solution:

        public void Configure(IMonoRailConfiguration configuration)

        {

            configuration.ViewEngineConfig.ViewPathRoot = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Views");

            configuration.ViewEngineConfig.ViewEngines.Add(new ViewEngineInfo(typeof(NVelocityViewEngine), false));

 

            configuration.ConfigurationSection = new MutableConfiguration("monorail");

            configuration.ConfigurationSection.Children.Add(

                new MutableConfiguration("exception")

                    .CreateChild("exceptionHandler")

                    .Attribute("type", typeof(EmailHandler).AssemblyQualifiedName)

                    .Attribute("mailTo", "to@email.com")

                    .Attribute("mailFrom", "from@email.com"));

 

            configuration.ExtensionEntries.Add(

                new ExtensionEntry(typeof(ExceptionChainingExtension), new MutableConfiguration("")));

        }



This code sets up the EmailHandler that comes with MonoRail.

Thursday, October 18, 2007

MonoRail Routing Upgrade Coming

I just did an update from the Castle repository, and look what I found:


Looks like we may be seeing improved routing capabilities in MonoRail soon. Isn't open source grand?

Wednesday, October 17, 2007

Castle MonoRail vs Microsoft MVC

Everyone seems to be chiming in on the newly announced MVC framework from Microsoft. A lot of the posts seem to be very positive.

The most talked about features seem to be:

  • Routing

  • Mockable IHttpRequest/IHttpResponse

  • Type-checked views


The routing feature seems pretty nice, but how far is MonoRail from having this feature? I think that MonoRail is missing this feature mainly because it wasn't developed in the era of IIS6.

IIS7 as I understand it gives the web application access to the web request earlier than IIS6, which gives it more control over the routing capabilities. Currently, IIS6 is not really well suited to be able to handle routing requests when there's no file extension on the URL. I imagine that this feature could be added fairly quickly once there's more motivation and more adoption of IIS7.

The mockability of IHttpRequest and IHttpResponse is a pretty nice feature as well, but couldn't MonoRail do this? Scott Guthrie said that they didn't change ASP.NET at all to get this feature.

Couldn't MonoRail wrap the standard HttpResonse and HttpRequest objects with adapters that implement a similar interface? The major hurdle with this seems to be that this wasn't done in the first place, and there's a lot of code out there that would have to change to use the new interfaces.

I have to admit that type-checked views sound enticing. It would be pretty cool to have refactoring operations automatically change things in the views.

But I've lived in a compiled view world and I really don't want to go back. If I have to recompile my project because I changed something in the view I would be pretty annoyed. It's already a huge annoyance to have to wait for the AppDomain to reload when I change something in a controller. I really don't want to wait for it to reload when I change a view as well.

I remember back in my Java/Struts days, I welcomed a switch in our project to Velocity over JSP files. There was a huge increase in productivity and I really didn't miss the type checking at all.

I love being able to submit a patch or jump on the Castle mailinglist to discuss a quick change that would help my own project and have the change implemented within hours or days. Wouldn't you lose that ability if you switched to Microsoft's MVC?

I guess that's a standard issue when deciding between open source and commercial frameworks. I'm really not ready to give that up, and I think that's one of the main reasons I'll be sticking with MonoRail as long as the project remains as active as it is.

Overall, I am pleased with the announcement. It seems that Microsoft is watching what is going on the community and trying to deliver a better platform for developing web applications.

My main point is that MonoRail is already a great platform that's in use by many, it's actively developed, and I'd be surprised if this new platform from Microsoft doesn't push it to greater heights. As always though, I'll be keeping an open mind as things unfold.

Wednesday, May 09, 2007

Exploring Castle Windsor/MicroKernel Auto-wiring

Castle Windsor/MicroKernel is a great tool for dependency injection. For most applications, the auto-wiring features of MicroKernel will perfectly for the your situation out-of-the-box. However, imagine a scenario where the dependencies of some components are services defined by an interface, while the dependencies of other components depend not on the interface, but rather on the specific implementation. Let's explore how we can get MicroKernel to help us out. So let's say we have this interface:

    public interface ISender

    {

        void SendMessage(string recipient, string message);

    }


and we have a couple of implementations:

    public class EmailSender : ISender

    {

        public void SendMessage(string recipient, string message)

        {

            // ... send email message ...

        }

    }


    public class InstantMessageSender : ISender

    {

        public void SendMessage(string recipient, string message)

        {

            // ... send instant message ...

        }

 

        public bool IsOnline(string recipient)

        {

            // ... check is user is online ...

            return false;

        }

    }


Suppose we have a component that requires a set a ISender services:

    public class AlertSystem

    {

        private ISender[] _senders;

 

        public AlertSystem(ISender[] senders)

        {

            _senders = senders;

        }

 

        public ISender[] Senders

        {

            get { return _senders; }

        }

 

        /// ... implementation ...

    }


OK, so far so good. Wiring this up with Windsor is a piece of cake:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <components>

    <component id="instant.message.sender"

              service="Eg.ISender, Eg"

              type="Eg.InstantMessageSender, Eg"/>

    <component id="email.sender"

              service="Eg.ISender, Eg"

              type="Eg.InstantMessageSender, Eg"/>

    <component id="alert.system"

              type="Eg.AlertSystem, Eg">

      <parameters>

        <senders>

          <array type="Eg.ISender, Eg">

            <item>${instant.message.sender}</item>

            <item>${email.sender}</item>

          </array>         

        </senders>

      </parameters>

    </component>

  </components>

</configuration>


But what if I have another component that requires a specific implementation of ISender like this:

    public class InstantMessageComponent

    {

        private InstantMessageSender _sender;

 

        public InstantMessageComponent(InstantMessageSender sender)

        {

            _sender = sender;

        }

 

        public InstantMessageSender Sender

        {

            get { return _sender; }

        }

 

        // ... implementation ...

    }


How can we get this wired up? Well, you might think just added the new component would work:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <components>

    <component id="instant.message.sender"

              service="Eg.ISender, Eg"

              type="Eg.InstantMessageSender, Eg"/>

    <component id="email.sender"

              service="Eg.ISender, Eg"

              type="Eg.InstantMessageSender, Eg"/>

    <component id="alert.system"

              type="Eg.AlertSystem, Eg">

      <parameters>

        <senders>

          <array type="Eg.ISender, Eg">

            <item>${instant.message.sender}</item>

            <item>${email.sender}</item>

          </array>

        </senders>

      </parameters>

    </component>

    <component id="instant.message.component"

              type="Eg.InstantMessageComponent, Eg"/>

  </components>

</configuration>


However, there is a slight problem with this. MicroKernel will not auto-wire components that have a dependency of InstantMessageSender because it is instead registered in the config for the service it provides, namely ISender. In this case, I can force the kernel to wire it up using the following configuration:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <components>

    <component id="instant.message.sender"

              service="Eg.ISender, Eg"

              type="Eg.InstantMessageSender, Eg"/>

    <component id="email.sender"

              service="Eg.ISender, Eg"

              type="Eg.InstantMessageSender, Eg"/>

    <component id="alert.system"

              type="Eg.AlertSystem, Eg">

      <parameters>

        <senders>

          <array type="Eg.ISender, Eg">

            <item>${instant.message.sender}</item>

            <item>${email.sender}</item>

          </array>

        </senders>

      </parameters>

    </component>

    <component id="instant.message.component"

              type="Eg.InstantMessageComponent, Eg">

      <parameters>

        <sender>${instant.message.sender}</sender>

      </parameters>

    </component>

  </components>

</configuration>


This works, but it's not autowired. If you have a lot of this going on in your system, you'll find yourself taking on more and more of the responsibility of wiring your components, even though you originally wanted to leverage MicroKernel to handle much of this for you. So let's say we want our configuration to look like the first configuration I presented. Well, we're going to have to change the way MicroKernel registers services. This concern is specifically handled via the NamingSubSystem. We will do the job by extending MicroKernel's default INamingSubSystem implementation, DefaultNamingSubSystem:

    public class CustomNamingSubSystem : DefaultNamingSubSystem

    {

        public override void Register(string key, IHandler handler)

        {

            Type implementation = handler.ComponentModel.Implementation;

 

            if (!service2Handler.Contains(implementation))

            {

                this[implementation] = handler;

            }

 

            base.Register(key, handler);

        }

    }


In this method, all we're doing is additionally adding the implementation to resolvable services if it isn't already. The DefaultNamingSubsystem only adds the service and not the implementation except in cases where you don't specify a service. Also note that this method should also take care of mapping the component id to the proper component. Here's the default implementation:

        public virtual void Register(String key, IHandler handler)

        {

            Type service = handler.ComponentModel.Service;

 

            if (key2Handler.Contains(key))

            {

                throw new ComponentRegistrationException(

                    String.Format("There is a component already registered for the given key {0}", key));

            }

 

            if (!service2Handler.Contains(service))

            {

                this[service] = handler;

            }

 

            this[key] = handler;

        }


And here's how I got Windsor to use my new DefaultNamingSubSystem:

    public class ApplicationContainer : WindsorContainer

    {

        public ApplicationContainer(string xmlFile) : base(xmlFile)

        {

        }

 

        protected override void RunInstaller()

        {

            Kernel.AddSubSystem(SubSystemConstants.NamingKey, new CustomNamingSubSystem());

            base.RunInstaller();

        }

    }


By the way, we could have gotten this all wired up if we registered the implementations twice: once for the service it provides and another time for the implementation, like this:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <components>

    <component id="instant.message.sender.service"

              service="Eg.ISender, Eg"

              type="Eg.InstantMessageSender, Eg"/>

    <component id="email.sender.service"

              service="Eg.ISender, Eg"

              type="Eg.InstantMessageSender, Eg"/>

    <component id="alert.system"

              type="Eg.AlertSystem, Eg">

      <parameters>

        <senders>

          <array type="Eg.ISender, Eg">

            <item>${instant.message.sender}</item>

            <item>${email.sender}</item>

          </array>

        </senders>

      </parameters>

    </component>   

    <component id="instant.message.component"

              type="Eg.InstantMessageComponent, Eg"/>

    <component id="instant.message.sender"

              type="Eg.InstantMessageSender, Eg"/>

    <component id="email.sender"

              type="Eg.InstantMessageSender, Eg"/>

  </components>

</configuration>


I wouldn't recommend this approach though.

Monday, April 30, 2007

Getting Started with NHibernate

I just found a good video introduction to NHibernate over at dnrTV created by Oren Eini (aka Ayende), who is an active NHibernate contributer. If you're an NHibernate pro, you probably won't find anything you didn't already know. I usually use Castle ActiveRecord instead of just using NHibernate directly in order to get a sizable productivity boost, provided the project is small enough. When a project is sufficiently large or complex (multiple client applications, large model, difficult mapping, etc), I believe that skipping AR and going directly to NHibernate is the way to go. It helps keep your laying cleaner by reducing coupling of your application services and the persistence mechanism.

Saturday, April 28, 2007

Rendering Binary Data with MonoRail

Sometimes you want to make your MonoRail controller render binary data for a download. MonoRail by default is setup to render HTML via the view engine, but you can change that behavior. I usually put a method like this in my base controller:

        protected void SetupDownload(string filename, string contentType)

        {

            CancelLayout();

            CancelView();

            Response.Clear();

            Response.ContentType = contentType;

            Response.AppendHeader("Content-Disposition", "attachment; filename=\"" + filename + "\"");

        }



By calling this method inside one of your controllers, you will change the default behavior of the controller to not perform the layout (CancelLayout()) and to not try to render a view via the view engine (CancelView()). The contentType should be something like "application/zip". It's the MIME type that is reported to the browser. This method also tells the browser that the data is not inline, and that the user should be prompted to download the file with a default filename provided by the filename argument.

So you have changed the default behavior of MonoRail to render something other than a plain vanilla view. All that's left is to write the binary data into the response's output stream. If you already have a stream, then you would do something like this:

        private void CopyStream(Stream from, Stream to)

        {

            byte[] buffer = new byte[_bufferSize];

            int bytes = 0;

            while ((bytes = from.Read(buffer, 0, buffer.Length)) > 0)

                to.Write(buffer, 0, bytes);

        }



            CopyStream(System.IO.File.OpenRead(path), Response.OutputStream);



Or, if you have a byte array (buffer in this example) or something similar, you can do something like this.

            Response.OutputStream.Write(buffer, 0, buffer.Length);



Notice that if you want to have the brower render something inline (e.g. an image), than you can just remove line that adds the Content-Disposition header that is in my example SetupDownload function.