Oren Eini

CEO of RavenDB

a NoSQL Open Source Document Database

Get in touch with me:

oren@ravendb.net +972 52-548-6969

Posts: 7,527
|
Comments: 51,163
Privacy Policy · Terms
filter by tags archive
time to read 3 min | 448 words

I'm starting a new project now, and I thought it might be worth while to blog how I'm starting out.

I started with the initial requirements, and then just let them sit in my head for a day or two. Just thinking about the abstract concepts and trying things out without actually having to put something on paper or keyboard.

Then I created a new project in VS, and started with the class diagram. I just put down a single class and several interfaces, and a few methods. I am using this to focus my thoughts, and there isn't any code that I have written there. Then I opened a word document and start putting down the assumptions.

Those can be high level stuff like "The service will have its own dedicate database" to low level things like "A task will not hold a thread for an extended periods of time". I don't write why those are important, it is not important now. What is important is to figure out the constraints that I am going to work with, and what I assumptions I decide will drive the architecture.

Then I usualy either walk and mutter to myself, or blog about it ( :-) ) about something, and let things fall into shape. I find that putting things to words, either via texts or speaking them out loud helps me organize my thoughts into coherent structures. This is part of the reason that I blog. It keeps me organize.

I usually consider what tools I need to do the work, and what tools I can bend to make my job easier. Active Record is an awesome rule processor, if you know look at it just right. And Windsor is the ultimate configuration manager that you can want.

The next step is to create a test project, and write the first test. This can take a while. I'm futzing with ideas, and I am never sure what direction I will take the project. This is usually one of the hardest part for the project, because there are too many possiblities. I can spend quite a bit of time trying things out, either in code or in diagrams.

At that point I then start coupling my design, so it would actually be usable. This means that I go from things like ICommand to IFileCommand, because that needs the file it works on, etc. Once I reach this point, I have no more reasons to procrascinate and I need to start writing the actual application :-) 

time to read 1 min | 140 words

I arrived to work one day, and I meet this guy just as I setup my laptop for the morning. He noticed that I have the task bar set to three lines height, and he couldn’t understand why I was doing this. I am also the only developer I know personally who uses dual monitors  regularly.

Both the height of the taskbar and the dual monitors are not indulgences, I need them to actually work effectively. Take a look at my task bar at the moment:

 

 

And that is not uncommon. Add a couple of debug sessions, a few emails that I am in the middle of answering to, a couple more notepad windows, and I would completely lose track of what I am doing.

How does your taskbar looks like at the moment?

On Naming...

time to read 1 min | 164 words

After reading Oren's post about naming interfaces, I started to notice how I name my interfaces.

My own contribution to the "interface names that give me a chuckle" is IHaveNameAndId and IDecideWhenToStartTask, which I just created. I am probably going to rename that one, though.

And, as long as we are dealing with naming. I got an outstanding bug that read like this: "Rename Fetch class to something that actually have a meaning." This class has a single method (well, one mehtod, several overloads) that looks like this:

comboBox.DataBind = Fetch.IdAndDescription( ... ) ;

Together with the method name, it actually makes sense, but I am not sure if this is a good practice. Then again, I can't really think of a good name for that one.

Semi Statics

time to read 6 min | 1111 words

I talked about Static pros and cons before. I also promised that I would post my solution to that. To sumrise for those who don't want to read the previous posts:

  • Statics make it easy to access functionality from anywhere in the application.
  • They allow cross cutting concerns to be handled easily by infrastructure code.
  • It is hard to make them safe for multi threading.
  • It is usually hard to test code that uses singletons.

My solution for that is to use a piece from Rhino Commons, the Local.Data hash table. This allow me to put objects that are assured to be local to my current execution, regardless of whatever I am running in a windows or web scenario.

Once I have that, I can create this class:

As you can see, this is a static class* with. The implementation is trivial:

public static class Context

{

       const string DbConnectionKey = "Db.Connection.Key";

 

       public static IDbConnection DbConnection

       {

              get

              {

                     IDbConnection connection = Local.Data[DbConnectionKey] as IDbConnection;

                     if (connection == null)

                           throw new InvalidOperationException("Context was not initialized properly");

                     return connection;

              }

       }

 

       public static IDisposable Initialize(IDbConnection connection)

       {

              LocalData.Data[DbConnectionKey] = connection;

              return new DisposableAction(delegate { Dispose()); }) ;

       }
  . . .

}

The usage is also simple, let us say that I want to do some operation that require the database.  I have some infrastructure code that handles the basic interactions. On the web, I usually use an Http Module that takes care of initializing and disposing the context. On Win Forms, I use the controller in MVC to take care of this (if the application is complex enough to demand this). The simplest scenario is a Windows Service. There I have some sort of coordinator that dispatch work, and it takes care of it, like this:

public void DispatchWork()

{

       IDbConnection connection = GetConnectionFromSomewhere();

       using (Context.Initialize(connection))

       {

              //Do work within this context

                }
}

I initialize the connection, and then I can do the rest of my work (usually by calling other classes who pre-condition is that the context is initialized).  I found that this approach combines both thread safety and the convenience of using static. Because there is only a single thread of execution (even if it is a logical one), there will not be surprises because of this. In the first post about statics, I gave an example of the IDbConnection blowing up because two threads access it in the same time. Using this approach, there is only a single thread, and it is consistent. If it will blow up, it will always blow up.

I may be in the middle of process an IDataReader, and call another method that tries to read from the database, this will fail immediately, since the second method will try to read and that is (generally) not allowed when a data reader is already opened. There are no surprises there, and that is very important thing.

To talk in patterns, it is a Service Locator. Personally, I find that the Context class becomes the speed dial into the rest of the application. I try to keep my context as lightweight as possible, but I put common methods there as well (see the IsAllowed() above for example of that). One thing that I insist on is that everything that the context allow access to will be mockable. Usually this mean returning an interface. When I need to test the code, I simply replace the implementation (either using the initializer or by going directly to Local.Data[] and modifying that entry).

But what about the Is Allowed method? It is a static method, and that can’t be mocked. The Is Allowed method just make a call to the security service in the Context (not shown here), and that can be mocked. In this case, it is just a short cut to make it easier to follow the Law of Demeter and to save repeating code.

There are some disadvantages, you lose the ability to look at a class’ interface and tell what the dependencies are. It may pull stuff from the context to do its work, and you will need to look at the code to understand how / where / what it does with it.

Another approach to this is the use of dependency injection. Castle’s Windsor has some very nice integration facilities for doing this, but without the need for the Context. In this project, it was not applicable because of customer’s demand.

* Just to note, in my own implementation I actually use a normal class, and extend the Context in several ways. It is all static, of course, but it is nice to know that each part of the application uses the same context consistently

 

Rhino Commons

time to read 2 min | 352 words

I made some updates to my commons library. It is just a set of utility classes that I find useful. At the moment it contains:

The thing that I use more than anything, though, is local data handling. I am pretty sure that I blog about this before, but I can't find it now.  The idea is to give you a simple hashtable of values that you can rely throughout your code. If you are working in Web context, it is using the Context.Items hash, and if you are working in a non-web context, you use a thread static hashtable.

This allows me to ignore where I am, and put stuff there that I know are private to my current logical thread of excutions.

You can find the bits here

time to read 7 min | 1218 words

I have recently created a grid that inherits from GridView, and add special processing. As part of the processing, I needed extra information about the data beyond just the list of items. I created a Bind() method that gets all the information, and handles the entire data binding scenario.

But this is not a common approach, and it is entirely possible that another developer will forget / not know that he needs to call this method  and use the following to add data to the grid:

grid.DataSource = foo;
grid.DataBind();

This would completely bypass my custom handling, and can lead to hard to discover bugs, after all, the code will look correct. In order to solve this issue, I used this approach:

[Obsolete("Use the Bind() method instead.", true)
public override object DataSource
{
    set
    {
        if(this.DesignMode==false)
    
       throw new InvalidOperationException(@"Can't use this setter.
                            You must use the Bind() method instead"
);
    }
}

I overrode just the setter for the DataSource property (something that I learned was possible only today), and added a compiler error when using this, as well as a runtime error. Both of those will direct the developer in the right path. I added the exception because the developer may call the class via is base class ,which will bypass the compiler obsolete error .

Update: Just to clarify, this is the Bind method, it does more than just

public void Bind<T>(ICollection<T> itemsToBind, ISecurable securable) { ... }

I added the bolded part to allow the control to work with the designer.

FUTURE POSTS

No future posts left, oh my!

RECENT SERIES

  1. RavenDB Cloud (2):
    26 Nov 2024 - Auto scaling
  2. Challenge (75):
    01 Jul 2024 - Efficient snapshotable state
  3. Recording (14):
    19 Jun 2024 - Building a Database Engine in C# & .NET
  4. re (33):
    28 May 2024 - Secure Drop protocol
  5. Meta Blog (2):
    23 Jan 2024 - I'm a JS Developer now
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats
}