петък, 25 юли 2008 г.

C# IoC Framework

Castle (IoC Framework and Container) is an open source project for .net that aspires to simplify the development of enterprise and web applications. Offering a set of tools (working together or independently) and integration with others open source projects, Castle helps you get more done with less code and in less time.
Castle consists of:
  1. MonoRail - MVC framework inspired by ActionPack, a paradigm shift to simplicity.
  2. ActiveRecord - The enterprise data mapping pattern implemented using NHibernate
  3. MikroKernel - A lightweight inversion of control container core
  4. Windsor Container - Augments the MicroKernel with features demanded by most enterprise projects
Related topics: Inversion of Control, Dependency Injection, Apache Avalon, Apache Excalibur, Castle, Spring, Spring.Net, Hibernate, NHibernate.


Interface injection


Spring doesn't offer support for interface injection as Fowler described it, but Spring does provide a couple types of "autowire" capabilities. Autowire is a means of automagically invoking setters on a target object by looking for source objects in the entire Spring context. If the target object has a setter that takes a single parameter, the type of that parameter is located in the Spring context. If Spring knows of any bean that matches the setter's type, it will invoke the setter.

As an example, if a JavaBean in Spring is set to "autowire=byType" and has a method signature of void setProperties(Properties props), Spring will look for a bean in its context that is of type Properties. If it finds one, it will pass it to the target bean's setter method. If it finds more than one source object of type Properties it will throw an exception.

Spring also has another type of autowire that uses the name of the setter property and looks for a source object with the same name. If found, the source object is passed to the target object's setter method...

As noted above, Spring's support of Interface Injection is an all or nothing approach and cannot be controlled very well. Autowire by type is a very magical type of IoC that proves too loose in many large applications, primarily because there isn't an efficient way to tell Spring which methods should be autowired and which ones are strictly off-limits....

The framework enables "autowiring" by default. To change the wiring mode, modify the spring.autowire property.

The autowire property can be set to several options: name, type, auto, constructor.


четвъртък, 24 юли 2008 г.

Maven properties (build.properties) -Properties Reference

The properties files in Maven are processed in the following order:

  1. Built-in properties are processed
  2. ${basedir}/project.properties (basedir is replaced by the directory where the project.xml file in use resides)
  3. ${basedir}/build.properties
  4. ${user.home}/build.properties
  5. System properties
* build.properties stores the path of local repository too

The built-in properties are specified in the plugin.properties file of a plugin, or in defaults.properties within Maven itself.

Both the project.properties and build.properties files in the project directory are also inherited along with the related project.xml file.

The last definition takes precedence, so ${user.home}/build.properties will override anything specified in a project, and properties given on the command line using -D will override everything.

Note: there are no per-user defaults, as there has not been a property shown where this concept makes sense. Currently, there are also no site-wide defaults, however this is planned for future versions of Maven.


вторник, 22 юли 2008 г.

Protocol Buffers - Google's Data Interchange Format

Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages – Java, C++, C#, Python and Perl.

It is used everyone inside Google.
The initial version Proto1 was developed in Google starting in early 2001.
Proto2 is a complete rewrite, though it keeps most of the design and uses many of the implementation ideas from Proto1. Some features have been added, some removed. Most importantly, though, the code is cleaned up and does not have any dependencies on Google libraries that have not yet been open-sourced...

Do we write hand-coded parsing and serialization routines for each data structure? Well, we used to. Needless to say, that didn't last long. When you have tens of thousands of different structures in your code base that need their own serialization formats, you simply cannot write them all by hand.

Instead, we developed Protocol Buffers. Protocol Buffers allow you to define simple data structures in a special definition language, then compile them to produce classes to represent those structures in the language of your choice. These classes come complete with heavily-optimized code to parse and serialize your message in an extremely compact format. Best of all, the classes are easy to use: each field has simple "get" and "set" methods, and once you're ready, serializing the whole thing to – or parsing it from – a byte array or an I/O stream just takes a single method call...
And, yes, it is very fast – at least an order of magnitude faster than XML.


Effective Java programming v2

Today I have been decided to put in my blog examples and recipes from the book - Effective Java programming, v2