blog.fossmo.net

At work we had a discussion about storing files in the database (SQL Server 2005) is a good thing or not. I searched the Internet, and found this paper. It says that storing files in a database (blob) is better if the file size is less than 256 kb. If the file size is larger than 1 Mb, it's recommended to store the files in the file system. Nice to know!

SQL Server 2008 supports the "datatype" filestream. 

I found this at Microsoft's website:

"The new SQL Server 2008 FILESTREAM data type allows large binary data like documents and images to be stored directly in an NTFS file system while letting the data document  remain an integral part of the database and maintaining transactional consistency. The new FILESTREAM data type enables the scale-out of large binary data, traditionally managed by the database, to be stored outside of the database on more cost-effective storage without comprising features for accessing such data. IT administrators can take advantage of all the rich database services like security, backup etc on top of these documents."

I suppose this will give us the best from both worlds?

Tags:

If you think my posts are ridiculously bad or if I, in a stroke of luck, posts something interesting, don't be afraid to give me feedback. One of my ground philosophies are that most of us can't improve without feedback. If someone does a good job, let's say at work, it's very important to tell them. Likewise, if someone doesn't do such a good job, they need to get that information to improve. Negative feedback, of course, need to be told in a more gentle way.  Don't just go up to a co-worker and say: "Your programming skills suck!". Try to be constructive and tell him/her what he/her needs to focus on, but don't shade the problems. Be honest.

I like to focus on positive feedback. If you work in a project team, the best way to get people more inspired is to tell them they are doing a good job.

Finding positive things to say, is often more difficult than finding negative things. In a project I worked on, we were told to sit down and look for positive and negative sides about how our team worked. We found a lot more negative than positive. When I thought about the team and the work a bit later, I came to the conclusion that there were just as many things that were positive as negative. Even more positive than negative stuff. I think it's easier to focus on the negative things, so I guess we have to put a little more energy into finding positive things to focus on.

If you want to build a better team or get people to do their best, give them feedback. Mainly positive.

I guess one of the most valuable characteristic a person can hold, is the ability to take feedback and filter out what's constructive and then adapt to it.

A person I worked with, had low self-confidence and lacked interest, to a degree, for the project we were working on. He was given feedback, mostly positive, and after some weeks he was one of the leading developers in the project. It was a real nice experience.

Please help me improve my blog by giving me feedback!

Tags:

The factory method pattern is a creational pattern. You can use it when you don't know witch object you must use at runtime.

Advantage of this pattern; you can delay assigning action code till more information is available. It's also easy to add other classes (in the code example below; color classes).
 

What happens in the figure above?

The first thing that happens, is that a parameter is passed into the GetInstance method in the Factory class. Depending on the parameter passed in, a object is returned. In this instance, a object from class Blue is returned. The factory method pattern is as simple as that. If I wanted to work with the Green object, I would have passed Green as a parameter.

This patterns can be used in all parts of your code. You can use it to choose, for instance, databases or different graphical user interface frameworks at runtime.

Let's look at some code:

   1:  using System;

   2:   

   3:  namespace FactoryPattern

   4:  {

   5:      // Color objects to choose

   6:      enum MyColors

   7:      {

   8:          Green, Blue

   9:      }

  10:   

  11:      // The contract the objects have to implemet

  12:      interface IColor

  13:      {

  14:          void ShowFavoriteColor();

  15:      }

  16:   

  17:      class Factory

  18:      {

  19:          // A instance of a object is returned based on the input parameter.

  20:          public IColor GetInstance(MyColors type)

  21:          {

  22:              IColor color = null;

  23:   

  24:              // Whice object to return is decided.

  25:              switch (type)

  26:              {

  27:                  case MyColors.Green:

  28:                      color = new Green();

  29:                      break;

  30:                  case MyColors.Blue:

  31:                      color = new Blue();

  32:                      break;

  33:              }

  34:              return color;

  35:          }

  36:      }

  37:   

  38:      class Green : IColor

  39:      {

  40:          public void ShowFavoriteColor()

  41:          {

  42:              Console.WriteLine("My favorite color is green");

  43:          }

  44:      }

  45:   

  46:      class Blue : IColor

  47:      {

  48:          public void ShowFavoriteColor()

  49:          {

  50:              Console.WriteLine("My favorite color is blue");

  51:          }

  52:      }

  53:   

  54:      class ColorChooser

  55:      {

  56:          public static void Main()

  57:          {

  58:              Factory factory = new Factory();

  59:   

  60:              // Decides which instance to start

  61:              IColor baseClass = factory.GetInstance(MyColors.Blue);

  62:   

  63:              // Executes method in chosen instance

  64:              baseClass.ShowFavoriteColor();

  65:   

  66:              Console.ReadKey();

  67:          }

  68:      }

  69:  }

Tags:

Dependency Injection (DI) is a fancy word for a very simple pattern. You probably use DI at some sort every time you code. In it simplest form, a variable is injected into a method and the method can interact with the variable. That's DI.

I often use DI in a other pattern called Model View Presenter. 

In the figure below, I visually try to show how DI works.

(Click on the image to view larger)

Below is a example of how I often use the pattern.

   1:  namespace DependencyInjection

   2:  {

   3:      class Program

   4:      {

   5:          static void Main(string[] args)

   6:          {

   7:              Class1 class1 = new Class1();         

   8:          }

   9:      }

  10:   

  11:      public interface IProperties

  12:      {

  13:          string MyValue { get; set; }

  14:      }

  15:   

  16:      public class Class1:IProperties

  17:      {

  18:          string _myValue = "Class1 value";

  19:          Class2 class2;

  20:   

  21:          public Class1() 

  22:          {

  23:              Console.WriteLine(MyValue);

  24:              class2 = new Class2(this);

  25:              class2.ChangeMyValue();

  26:              Console.WriteLine(MyValue);

  27:              Console.ReadKey();

  28:          }

  29:   

  30:          public string MyValue

  31:          {

  32:              get

  33:              {

  34:                  return _myValue;

  35:              }

  36:              set

  37:              {

  38:                  _myValue = value;

  39:              }

  40:          }     

  41:      }

  42:   

  43:      public class Class2

  44:      {

  45:          private IProperties _view;

  46:   

  47:          public Class2(IProperties view)

  48:          {

  49:              _view = view;

  50:          }

  51:   

  52:          public void ChangeMyValue()

  53:          {

  54:              _view.MyValue = "Changed by instance of Class 2";

  55:          }

  56:      }

  57:  }

In line 7, a instance of Class 1 is created. The constructor in Class 1 is executed (line 21). 

Class 2 is called with the instance of the current object (Class 1). 

This is possible because Class 1 implements the interface IProperties (line 11). In line 25, class 2

calls the method ChangeMyValue. The property MyValue in Class 1 is changed.

That's the dependency injection pattern.

Tags: