My project setup, Part 1 - Initialization

by Jakobsson 4. March 2010 19:14

A while ago I wrote a post about what tools and frameworks I use in my web applications. Now I thought I'd write a small series about how I use those tool. In this first part I'll write about the initial setup and how I use my ioc container.

A lot in my applications revolve around my ioc container. I try to make it take the heavy lifts to make my coding easier. I have created a base bootstrapper that doesn't depend on a specific container. That class looks like this:



    public abstract class BootstrapperBase : IBootstrapper
    {
        private readonly List<Assembly> assemblies = new List<Assembly>();

        protected BootstrapperBase(IEnumerable<Assembly> assemblies)
        {
            this.assemblies.AddRange(assemblies);
        }

        public virtual void Execute()
        {
            ExecuteCore();
            SetServiceLocator();
            ServiceLocator.Current.GetAllInstances<IInitializationTask>()
                          .ForEach(x => x.Execute());
        }

        protected IEnumerable<Type> GetAllTypesInAssemblies<T>()
        {
            return
                GetAssemblies().SelectMany(
                    x => x.GetTypes().Where(y => typeof(T).IsAssignableFrom(y) && typeof(T) != y));
        }

        protected abstract void ExecuteCore();
        protected abstract void SetServiceLocator();

        protected virtual IEnumerable<Assembly> GetAssemblies()
        {
            return assemblies.Distinct();
        }
    }


It's quite simple. It takes a list of all assemblies that should be searched when I initialize my ioc container. Then it has a Execute() method (from the IBootstrapper interface). This basicly calls the ExecuteCore() abstract method that will initialize the container. Then it calls the SetServiceLocator() abstract method that will set a servicelocator for the ioc I'm using. Then it uses the servicelocator to get all instances of IInitializationTask and call the execute method on them.

The IInitializationTask interface looks like this:



public interface IInitializationTask
{
    void Execute();
}



Very simple with just one method, Execute(), that will execute the task. Everything that I want to initialize at the start of the application implements this interface. This could be registering my routes, setting up automapper or anything else that you want to execute on application startup.

Now I need a implementation of my base bootstrapper for the ioc container I want to use. My favorite is structuremap. And here is my bootstrapper for structuremap:



public class StructureMapBootstrapper : BootstrapperBase
    {
        public StructureMapBootstrapper(IEnumerable<Assembly> assemblies)
            : base(assemblies)
        {

        }

        protected override void ExecuteCore()
        {
            ObjectFactory.Initialize(x =>
            {
                GetRegistries().ForEach(x.AddRegistry);

                x.Scan(y =>
                {
                    y.WithDefaultConventions();

                    GetAssemblies().ForEach(y.Assembly);

                    y.AddAllTypesOf(typeof(IInitializationTask));
                    y.AddAllTypesOf(typeof(IConsumer<>));
                });
            });
        }

        protected override void SetServiceLocator()
        {
            ServiceLocator.SetLocatorProvider(() => new StructureMapServiceLocator());
        }

        protected virtual IEnumerable<Registry> GetRegistries()
        {
            var types = GetAllTypesInAssemblies<Registry>();
            return types.Select(x => (Registry)Activator.CreateInstance(x));
        }
    }



The interesting part here is the ExecuteCore() method. It initializes structuremap and first it adds all the implementations of the structuremap Registry class that it can find in the assemblies of the application. Then it scans all applications and adds all classes that implements the interface IInitializationTask (that I described earlier). Then it adds all classes that implements the IConsumer<> interface. I use the IConsumer<> to subscribe to events that I can publish from my application. You can read how that is done in this post.

Now i just need a way of calling my bootstrapper in my application. For this I have first created a MvcApplicationBase class. This is a class that inherits from the HttpApplication class. It looks like this:



public abstract class MvcApplicationBase : HttpApplication
{
    private IBootstrapper bootstrapper;

    public IBootstrapper Bootstrapper
    {
        get
        {
            return bootstrapper ?? (bootstrapper = CreateBootstrapper());
        }
    }

    public void Application_Start()
    {
        Bootstrapper.Execute();
        OnStart();
    }

    public void Application_End()
    {
        OnEnd();
    }

    protected abstract IBootstrapper CreateBootstrapper();

    protected virtual void OnStart()
    {
    }

    protected virtual void OnEnd()
    {
    }
}



This is pretty simple. It has a abstract method, GetBootstrapper(), that I call to get the bootstrapper and executes it in the Application_Start() method.

Then I need a implementation of this class for my structuremap. This class looks like this:



public abstract class StructureMapMvcApplication : MvcApplicationBase
{
    protected StructureMapMvcApplication()
    {
        BeginRequest += delegate
                            {
                                ServiceLocator.Current.GetInstance<IEventPublisher>().Publish(new BeginRequest(this));
                            };
        EndRequest += delegate
                          {
                              ServiceLocator.Current.GetInstance<IEventPublisher>().Publish(new EndRequest(this));
                          };
    }

    protected abstract IEnumerable<Assembly> GetAssemblies();

    protected override IBootstrapper CreateBootstrapper()
    {
        return new StructureMapBootstrapper(GetAssemblies());
    }
}



Here I publish two events when a request begins and when a request ends (explained in the link I gave earlier). Then I override the GetBootstrapper() method and creates a instance of my StructuremapBootstrapper. I also have a abstract method, GetAssemblies(), that will return all assemblies I want to search when I initialize structuremap.

All the code from this post sits in a base assembly that I use for just about all my applications. It contains the basic generic stuff that I want to do in just about every web application. In my next post I will show you how this fits into the application and how I extend it with the application-specific initialization and how I set up nhibernate in my applications. Stay tuned.

Tags:
Categories: C#

Front end performance, the key to success

by Jakobsson 29. January 2010 18:09

Yesterday we had another one of our programming sessions that I was talking about in my last post. The subject for the day was front end performance and what we can do to make our sites faster. The meeting was based on Steve Souders book High Performance Websites. He is the developer behind YSlow, a must have plugin for firebug when you are optimizing your front end.

Only about 5 - 15% of the load time from a common website is from the actual server side rendering. The rest of the time is spent downloading scripts, stylesheets, images etc. So, the question is, why do we spend so much time trying to fix our "slow" sql queries? Isn't there a way we can work on our front end so that the client doesn't have to spend that much time downloading all our resources? Well, of course there is. Steve Souders have developed 14 rules that will make your site load faster if you follow them. I will not go through them now, but you can see the whole list here.

I think this is a very interesting subject and there is so much more we can do to make our site faster, and a lot isn't hard at all. It can be as easy as changing a setting in your webserver. I have written about this before, and I think its very important. You do not only help then client to render your site faster, you are also taking a lot of the load away from your servers when they have to serve less and smaller files. I would like to recommend this page. There you have a number of great videos from the yahoo team that are very helpful.

Tags:
Categories: General

My experiance with the prototype framework

by Jakobsson 15. January 2010 13:18

It has been a long time now since my last post. I have simply not found the time to write anything. But today I have a little spare time, so I tought I'd write a little bit about my experiance with the prototype javascript framework.

We have recently started a developer group in my home town, varberg, sweden. We have a meating every two weeks and we talk mostly about web development on the .net platform. Our last meating was yesterday where we disgussed different javascript frameworks. We decided to have a pair programming session where each pair was assigned a framework. Our task was to build a small photo gallery like this one.

I was assigned the prototype framework. I was pretty glad with this as I haven't tried it before and I wanted to test a more object oriented framework. I have mostly worked with jquery before wich is more about handling the DOM. We decided that we wanted to explore as much of the oo parts of the framework as possible. Even tough it was a pretty small task we decided to take the oo approch to the solution.

After working a bit with the framework I have to say that I'm very happy with it. I like the way they work with classes and I think it will help make the code more readable. It might not work to well in small web pages where there isn't much javascript. But in big application I think it realy shines. I will deffinatly look closer at the framework and try it out some more. And I really recomend it.

Tags:
Categories: Javascript

The war of the var keyword continues

by Jakobsson 20. November 2009 12:39

I don't know how many times I have read articles about the var keyword, and how "dangures" it is to the readability of your code. Yesterday Steve Wellens wrote about how misused the keyword is. I have to say that I couldn't disagree more.

First of all his example isn't a real world example:

var Data = GetData();

You need to be able to name your methods and variables better then that. But even in this example, I would use var. Even if it isn't clear what the return type is. How often has it actually helped you to see what the method returns from the type declaration? I can say that it doesn't help me at all. After all, the important thing isn't the type it self, but what methods and properties it contains. In my opinion, if you need to see the type from the declaration to have more readable code, you are doing something wrong.

Another common question about the keyword is (as for all new things in any language) "how well does it preform?". Well, the answer is very simple: exactly the same as if you where to explicitly set the type. The var keyword isn't a runtime feature, it's resolved at compile time. So the compiled code is the exact same.

And then we have another very common misunderstanding. That this code:

ICar car = new SportsCar();

is better then this:

var car = new SportsCar();

It isn't, it's actually worse if anything. You will still have a dependencie on the SportsCar class in this method while you are hiding functionality on the class. The reason why we program to interfaces instead of implementation is to avoid dependencies, and this code doesn't help us with that. The car object here can still be used in any function that takes a ICar. If you want to avoid a dependencie on the SportsCar class, then you should call a method to get it. And that method should return a ICar, and in that case the var keyword is the way to go when calling the method.

Yes, naming classes right is just as important as naming methods and variables. But in a different context. The use of the var keyword will gain you the ability for easier refactoring, a little bit faster coding (in general) and you will probably think twice when you name your variables and that is a good thing as it will help any other developer who is reading you code.

So, in my opinion, the var keyword can not be misused. I use it everywhere, and I feel my code is more maintainable and readable then with explicit typing.

Tags:
Categories: C#

Handling image uploads with Asp.Net Mvc

by Jakobsson 19. November 2009 19:21

A very common taks in web development is uploading images. This isn't realy a hard task in it self, but it can be pretty frustrating to write the same code over and over again even if its only a few lines.

In one of my current projects, I need to handle a lot of images. In many cases there are two or more image uploads in a view. That is code that I don't want to write more then once and I want to keep it out of my controller. Therefore I decided to create a model binder to handle this.

I started of by building a simple binder that just handeled the needs of our application. It was a binder for our Image object that pretty much just set the properties of the object (just like the default model binder except that I got the name from the uploaded file) and uploaded the file to our upload map on the server.

Then I wanted to generalize the the binder so that I may reuse it in a easy manner in my other projects. I talked to my friend Magnus about this, and together we came up with the following idea.

One new requirement was that we wanted to save the image from the controller (after we save the data to the database) by just calling a save method on the image object. This will gain us the advantage of beeing able to not save the image to the disk if, for some reason, the database save generates a error and the data isn't saved. Another advantage is that we are now able to select where we should save the image from the controller, so we can save different images in different maps.

I decide to create a base model for a image that you can inherit from if you need to save some other data about the image more then just the file name. Here is how that class looks like:

public class ImageFile {

protected ImageFile(HttpPostedFileBase file) {

File = file;

Name = file.FileName;

}

public virtual string Name { get; protected set; }

protected HttpPostedFileBase File { get; private set; }

public virtual void Save(string virtualPath) {

var path = HostingEnvironment.MapPath(virtualPath);

if (string.IsNullOrEmpty(path)) throw new FileNotFoundException();

File.SaveAs(string.Format("{0}{1}{2}", path, (path.EndsWith("/") ? string.Empty : "/"), File.FileName));

}

}

This class simply takes a HttpPostedFileBase and has the ability to save it to the disk with a simple method call. Then we have the model binder it self that looks like this:

public class ImageFileModelBinder<T> : IModelBinder where T : ImageFile {

    public virtual object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext) {

        var key = GetKay(controllerContext, bindingContext); if (string.IsNullOrEmpty(key)) return null;

        var file = controllerContext.HttpContext.Request.Files[key];

        if (file == null || file.ContentLength < 1) return NoFileFound(controllerContext, bindingContext);

        var image = GetFile(controllerContext, bindingContext, file);

        BindProperties(image, controllerContext, bindingContext, file);

        return image;

    }

    protected virtual T NoFileFound(ControllerContext controllerContext, ModelBindingContext bindingContext) { return null; }

    protected virtual string GetKay(ControllerContext controllerContext, ModelBindingContext bindingContext) {

        return controllerContext.HttpContext.Request.Files.AllKeys.Where( x => x.ToLower().Contains(bindingContext.ModelName.ToLower())).FirstOrDefault();

    }

    protected virtual T GetFile(ControllerContext controllerContext, ModelBindingContext bindingContext, HttpPostedFileBase file) {

        var construct = typeof(T).GetConstructor(new[] { typeof (HttpPostedFileBase) });

        return construct.Invoke(new object[] { file }) as T;

    }

    protected virtual void BindProperties(T image, ControllerContext controllerContext, ModelBindingContext bindingContext, HttpPostedFileBase file) { }

}

This is a generic class where the generic type must inherit from ImageFile. As you can see I decided to put in a few extension points in this binder. First we have the method "NoFilFound()". This method basicly is there if you want a default image to be returned if there is no uploaded file. In this default binder we simply return null. Then we have have the "GetKey()" method. This is there to provide the key for the uploaded image, or the name of the file input field. It has a default implementation that is based on the name of the model. After that we have a "GetFile()" method. This is the method where we acctually initialize the image object. In this defaul implementation we use reflection and use the constructor of the ImageFile object. If you don't have a constructor that takes only the posted file as a parameter, you need to override this method. Our last method is "BindProperties()". This is simply there to add extra data to our implementation of ImageFile if we need any.

Now that we have our base classes we can start using them in a real world applicaiton. In the application I was talking about here, we needed to know the width and height of the images we uploaded as well. So I needed to create my own classes. Here is how my image object looked like:

public class ImageFileFormModel : ImageFile {

private readonly IFileSystem _fileSystem;

public ImageFileFormModel(HttpPostedFileBase file, IFileSystem fileSystem) : base(file, bindingContext) {

_fileSystem = fileSystem;

}

public int Width { get; set; }

public int Height { get; set; }

public override void Save(string virtualPath) {

_fileSystem.WriteFile(string.Format("{0}{1}{2}", virtualPath, (virtualPath.EndsWith("/") ? string.Empty : "/"), File.FileName), File.InputStream);

}

}

Other then the Width and Height properties I also override the default Save() method and use a IFileSystem interface. This is basicly a wrapper with methods that handle different file system tasks, like saving a file. I take that interface as a parameter in my constructor.

I also needed to create my own binder. The binder looks like this:

public class ImageFileFormModelBinder : ImageFileModelBinder<ImageFileFormModel> {

private readonly IFileSystem _fileSystem;

public ImageFileFormModelBinder(IFileSystem fileSystem) {

_fileSystem = fileSystem;

}

protected override ImageFileFormModel GetFile(ControllerContext controllerContext, ModelBindingContext bindingContext, HttpPostedFileBase file) {

return new ImageFileFormModel(file, _fileSystem);

}

protected override void BindProperties(ImageFileFormModel image, ControllerContext controllerContext, ModelBindingContext bindingContext, HttpPostedFileBase file) {

var img = Image.FromStream(file.InputStream);

image.Width = img.Width;

image.Height = img.Height;

}

}

 

This is pretty simple. I override the GetFile() method as I have a constructor with two parameters (the IFileSystem as well) and I override the BindProperties() method as I need to set the width and height of the image as well.

When you have this set up and you have registered the model binder you can easily use it in any action. Here is a example from our application where we have two images we need to save in one action:

[AcceptVerbs(HttpVerbs.Post), Authorize] public ActionResult Create(CreateFormModel house) {

var saved = _houseService.Add(Mapper.Map<CreateFormModel, HouseDto>(house));

house.MapImage.Save("~/Upload/Images/");

house.ProductImage.Save("~/Upload/Images/");

return RedirectToAction("HouseImages", new { id = saved.Id });

}

 

This is only a first version, and there is probably some things that will changes in the future as we use it in more applications. But right now I'm pretty happy with it and it serves my needs very well. If you have any sugestions, feel free to post them here.

Tags:
Categories: C#

What my toolbox looks like

by Jakobsson 16. October 2009 12:58

I guess that most developer have their favorite set of libraries that they use in just about every project. Atleast I have such a toolbox. They are tools that I find myself using constantly and that I feel help me in my development. Here comes my list.

1. Asp.Net Mvc

Well, I'm mostly a web developer so I need a nice web framework to start with. I feel that Asp.Net Mvc is the framework that I can be the most productive and have the most fun with at the moment. When I start a new web project in visual studio it's allways a mvc project.

2. NHibernate

If you have been reading my blog, you know that I'm a big fan of the OR/M NHibernate. I never build a web application without NHibernate as my data access layer.

3. Structuremap

Not to much to say here. I want to use a di/ioc container and structuremap is my personal favorite that is available for the .net framework.

4. Automapper

A great tool to map entities to viewmodels. It's easy to use and set up, and you will save a lot of left-to-right code by using it.

5. jQuery

If you want a nice looking UI at the client, a javascript library will help you a lot. My choise is jQuery. It's simple to use, has great support and there is a ton of great plugins.

6. NUnit

We need a testing framework if we should write test. My personal favorite is NUnit. It's simple and it works great.

7. Rhino Mocks

If we write tests we usually need a mocking framework as well. My choise here is Rhino Mocks. I have been using it for a while and it's working out great for me.

Those are the tools that I use in just about every web application I'm building. In my oppinion they make development a lot smother and more fun.

Tags:
Categories: General

Using partial views for javascript

by Jakobsson 7. October 2009 17:56

Lately I have been working on a web application that requieres quite a bit of javascript. I decided to use the Mvc pattern here that I have written about before to see how it works out and to get a more readable and seperated javascript code. I did want to seperate the view, model and controller from each other in different files to be able to get a better overview of the javascript code. It can be very hard to read javascript if you have line after line in the view it self and to be able to reuse the same parts in different similar views.

I stared out by creating different .js files for each view, model and controller that i was using. The problem with this is that you will end up with a lot of different requests. On top of the libraries and plugins you use on the page, you will have three more .js files to include. Another dissadvantage is that you will not be able to use any server side method, like ResolveUrl() or anything on you'r model, while rendering the javascript.

After a while I decided to abandon the .js files and go for partial views instead. This way you will be able to seperate the javascript in different files, you will be able to use server side methods while rendering and you will get advantage of the intellisense support in visual studio (you will get this in .js files as well). While at the client side, all javascript will be embedded in the same view without making a lot of requests to the server.This way you get the best of both worlds in my opinion. The only dissadvantage I can see from using external .js files is when you are debugging. It can be harder to find the function you want to debugg and to jump between functions in the browser as all javascript is rendered at the same place. However, with search functions like the one in firebug, this shouldn't be a issue.

Categories: Javascript

Why code blocks in the UI is a good thing

by Jakobsson 27. August 2009 12:50

A very common argument against the asp.net mvc framework is that people don't want to use server side code in the same place as you have the html code. Some say it makes the code unreadable or that it is a step backwards in development and closer to asp 3. In my opinion, this is a very thin argument that comes from developers that haven't even tried the framework. It is in no way like the old asp 3 days. The only thing that is close to it, is that you use code blocks to display dynamic data. And why is that less readable then using xml placeholders all over the html and use the code behind to populate the data? To me, maintaining a view that contain lots of literal controls and placeholders of any kind can be very hard and annoying when you have to go back and forth between the .aspx file and the code behind.

I agree that logic in the view between the html is hard to read. But why would you put that in the view? We have a lot of other places to keep that. But whats wrong with using a foreach loop to display multiple rows of data in the view? Isn't that view logic?

I decided to build two simple applications that displays a number of rows from a dynamic data source. I built one using the asp.net mvc framework and one using the asp.net webforms framework. Here is a screen shot of the mvc view:

Mvc view

And here is one of the webforms view:

Webforms view

This is a very simple example, but to me it shows how much easier it is to understand a mvc view then a webforms view. I think that a designer that only knows html and css would have a easier time changing the design of the mvc view then the webforms view. It is easier to see what is server side code and what is part of the design that the designer is changing. This makes it, in a way, more seperated, ironicly, when it is in the same place then if you split it in two files as in the webforms view.

I also decided to run a preformance test between the two applications. I published both applications to this server (the one my blogg is running on) and used firebug to see how fast each page was loading. I set EnableViewState to false in the webforms application, as I would not need it in such a view anyway. In the test I had 800 rows of data in the database that I displayed. This is not realy a real world scenario, but I decided to have quite a lot of rows to get some difference between the applications. The mvc view took just above 400ms to load in general, while the webforms view took about 570ms to load in general.

Now, you should not trust this test blindly as it is a very simple scenario that doesn't realy test what a real world application would do. I did it mostly out of curiosity to get a grip of the preformance differences between the two frameworks.

Personaly I would choose inline code blocks over xml placeholders any day. I think it leads to a lot more readable code. Of course you don't have to use the mvc framework to use inline code blocks, you can do it in the webforms framework as well.

What I'm trying to say here is that code blocks in the UI isn't a bad thing if you use it right. It can, many times, lead to a more readable html markup that is easier to follow. Just because we have inline code blocks doesn't mean that we are taking a step backwards in development.

Tags:
Categories: C#

Using the MVC pattern in javascript

by Jakobsson 20. August 2009 17:44

As anyone who have ever worked on a javascript heavy page knows, javascript can very easily get out of hand and become a mess. Roy Osherove thinks we should fix this problem by generating our javascript using a server side programing language. I didn't realy like this idea, nor did Jimmy Bogard. But the other day my friend, Magnus Bertilsson, showed me this nice article where Jonathan Snook talks about implementing the MVC pattern on the client side.

My first thought after reading the article was: "Why haven't I thought about this before?". It isn't realy a new idea, as there is a few frameworks out there already, but I have totaly missed that. It is pretty obvious, if we can use the pattern on the server side, why shouldn't we be able to do it on the client as well? To often you end up with a javascript method that respond to a event, ask the server for some data (ajax) and then displays it where it belongs. What if this could be separeted in 3 parts, one method to respond to the event, one that get the data you need and one to display it on the page? And all those methods will be seperated from each other in different objects. To me this seem like it can solve some of the maintainability issues you face while writing javascript.

I thought a little bit about how I would implement it. I decided I would have my controller and my model in two seperate .js files while I let the view sit in the html view. The reason I don't want the view in a seperate file is that it will only handle the html and I thought it would be easier to let it be as close to possible to the html. This gave me a file structure looking something like this:

My model will be responsible for getting all the data I need for the view. It can look something like this:

var Model = {
     getData: function(id) {
          [Ajax call to get data by id];
     }
}

Then I need a view to display this data. It would look something like this:

var View = {
     displayData: function(data) {
          [Edit the html in a desiered way with the new data];
     }
}

Then I just need the controller to get it all together. This could look something like this:

$(function() {
    $("#LoadDetails").click(Controller.details(1));
});

var Controller = {
     details: function(id) {
          var data = Model.getData(id);
          View.displayData(data);
     }
}

Here I handle the event binding in the Controller.js file. I could do it in the page as well, but for now I think its more logical to have it in the .js file as that is where the controller is that will handle the events. I'm thinking that each page (that need javascript on it) has one controller and one model. You can have multiple views to handle different things or parts of the page. I will have one model and one controller for the master page as well that all other pages can use. Here I can also have the methods that needs to be reused over more then one page.

This is what I'm thinking. I haven't acctually tried it out in any way yet. I will do that in my forum application when I get that far with it. I will think a little bit more about changes that can be made, and maby try out some existing framework as well.

It will, of course, not suite every application to structure your javascript in this way. Some pages don't have that much javascript and it's no problem to keep track of it anyway, and some developer teems might have some other pattern that suits them better. The good thing about the MVC pattern is that its nothing new, many developers allready know how it works and maby they are allready using it on the server side. Personaly I think it can solve a lot of my own problems.

Categories: Javascript

What I look for in a ORM

by Jakobsson 18. August 2009 18:09

In just about every application I build that use a relational database, I also use a orm tool to handle my data access. The reason I do this is to save myself the time it takes to handroll a data access layer in ADO.Net and to eliminate buggs that can come from writing sql queries. I do have a few things that I look for in a professional orm that I think is important:

  1. Transparancy
  2. Extensability
  3. Linq support
  4. Preformance

1. Transparancy

The most important feature of a orm, in my opinion, is that it should be transparant. This means that you, as a developer, should not constantly be remindad what tool you are working with. The orm itself should sit in the background and handle the persistance without you noticing it. You should, in my opinion, have a clean domain model that has no direct dependency on you'r orm while the mapping itself should be seperated from the domain. You should be able to, freely, shoose the types all the types on your model and map it to the underlaying database.

2. Extensability

No tool work perfect for every solution out of the box. This is why it's important to have extensability points that the developer can use to make it fit his/her needs. With a good architecture a tool can give the developer a very free hand on how he/she want's to extend it and make it fit any application.

Many extensability points will also encourage developers to create third party tools to help development with a certain orm. And when you find those tools that you like, it will speed up your development process, and you can focus on some other part of the application.

3. Linq support

Linq support is allways a good thing to have in a orm tool, as it is built into the language we use and we are used to use it in our every day work. It makes us write strongly typed queries and we are not forced to learn a new API or querying language. A good linq provider can mean a lot to a orm and help the developer eliminate "magic string bugs".

4. Preformance

Preformance is, of course, a very important part of a orm as it will handle a lot of trafic between the database and the application. The reason I put it last on my list is that it will not be a huge difference between two professional tool on basic CRUD queries. Most orm's will send very similar sql to the database for 90% of your queries. A orm should, however, be cacheing your queries and make sure you don't hit the database more then necessary.

Those are the features I think is the most important once to have in a professional orm. My personal choice is NHibernate, which I think cover those points pretty well. The one thing I think need improvment in NHibernate is the linq provider. This provider is still under development. Other then that, I think NHibernate is the most complete orm for the .Net framework.

Tags:
Categories: General