The official Fatica Labs Blog! RSS 2.0
# Friday, 27 April 2012

I described the “typed factory” concept here some days ago. The solution we looked at was requiring the Castle DynamicProxy dependency. If you want something simpler zero dependency and “just working” I creted a little hacking factory: AnyFactory. It is really simple and does not requires any external dependency, and can be integrated in your project by just adding a single file. I provided some documentation on the project wiki. The extension works by crafting a factory implementation using Reflection.Emit. It does not requires to configure anything since a unresolved dependency satisfying some restrictive rule is considered to be a factory, and the implementation is produced in the background.

the rules for an interface to be consider a factory are:

  • It is a public interface
  • Each method name starts with Create
  • Each method return something
  • There is no properties

The name is required to begin with Create, if it contains something after Create, this is considered to be a named binding to solve. Construction parameters can be specified, but there is a restriction: the parameter name should match the implementation constructor parameter name. ANother limitation is that we don’t support the “delegate” factory.

Friday, 27 April 2012 16:54:54 (GMT Daylight Time, UTC+01:00)  #    Comments [0] - Trackback
C# | Programming

# Wednesday, 25 April 2012

Yesterday I had an interesting discussion with a colleague about using IoC in the real world in a proper way, without falling back in the Service Locator Antipattern, and of course without having a reference to the container, that is just so horrible to not worth any word. So we both found the solution being the use of factories, supplied by the container, to create the on-the-fly requested components. I was used to craft these factories by hand, but I know is a little silly, especially when the colleague talked about the Castle(Windsor) typed factories. So quite interesting, but since I choose NInject as my IoC ( Castle was the first container I saw, and my first love too ) I felt the challenge to implement the same but… Fortunately ( well, for say it would be nice being the implementer ) Remo Gloor provided a NInject extension that does almost the same for this other beautiful container. A nice documentation is also available on the Github repository. So thanks to a discussion I improved my programming knowledge, the Ninject.extensios.factoy is added to my toolbox A bocca aperta

Wednesday, 25 April 2012 15:58:04 (GMT Daylight Time, UTC+01:00)  #    Comments [0] - Trackback
CSharp | Programming

# Thursday, 12 April 2012

There are scenarios in which NHibernate performance decrease even if we do all the effort to correctly use it. This could happen if we need in some circumstances to load a lot of record ( I explicitly use record instead of ‘Entity’ ) from some relational structures, and doing this the OR/M way means overload the session with a lot of entities, that is painful in term of speed. Other cases happens when we need to  write or update something that is not properly represented in the entity model we have, maybe because the model is more “read” oriented. Other cases? I’m not able to grasp all  of course, but I’m sure that you face some if you use an OR/M ( not necessarily NH ) in your daily basis. Using NHibernate an alternative could be using FlushMode=Never in session, but you still have all the OR/M plumbing in the hydrating entity code that negatively impacts the performances. I obtained impressive results in solving such a situation, by using Dapper, a so called single file OR/M. It is a single file that provider some IDbConnection extension methods, those methods works on an already opened connection, so we can use the connection sticked to the NHibernate open session, as here below:

// don't get confused by LinqToNh Query<> this one is the Dapper query
// acting on the CONNECTION :)

session.Connection.Query<MyDto>("select Name=t.Name,Mail=t.Mail from mytable t where t.Valid=@Valid",new{Valid=true});

you obtain back a big recordset of MyDto instances in almost the same time if you wire by hand a DateReader vertical on the dto, with all the error checking.

So why don’t use it always?

Because despite the name Dapper is not an OR/M, it does not keep track of modified entities, it does not help you in paginating results or lazy load the entity graph, neither helps in porting from one SQL dialect to another.

Is this strategy used somewhere else?

You probably find interesting to read this post by Sam Saffron, this solution is used in combined with the LinqToSql OR/M to help when the OR/M performance are not enough.

By my test I experienced a performance increase of 10x in a very hacking situation, but I can’t show the case since it is not public code. Something more scientific about performance is here.

Thursday, 12 April 2012 09:41:12 (GMT Daylight Time, UTC+01:00)  #    Comments [0] - Trackback
CodeProject | Dapper | NHibernate | ORM

# Tuesday, 03 April 2012

I talked about this one file utility here and here. I decided the syntax I create in the last improvement, for allowing the user to customize the exception to throw was not so usable, so I modified it. Now the resulting code to throw a specific exception is:

        /// Classical not null verification, with custom 
        /// exception and message
        public void DoSomethingWithCustomMessage(string arg1)
            Contract.Expect(() => arg1)
                .Throw((n)=>new Exception(string.Format("I'm unhappy to see that {0} is null",n)))


So there is no more any magic formatting, we just need to provide a function returning some kind of exception. The lambda argument (n) is the literal representing the name argument. I also added a wiki page on the project repository, to show the basic usage of the library so at a glance you can see how it works.

Tuesday, 03 April 2012 07:55:51 (GMT Daylight Time, UTC+01:00)  #    Comments [0] - Trackback

# Wednesday, 21 March 2012

Some days ago I came in this issue regarding thread non-safety when using MoQ. So I simple create my own fork on GitHub and solved the issue, that was really easy to do, and as a result I obtained a Mock stable even when mocked methods are called from multiple threads. I created a bounch of test to prove that worked, here below one as a sample:


So with this I made the Mock thread safe at the infrastructure level, that mean no more strange NullreferenceException and others. But what if we want our mock not thread safe? I mean there could be situation in which we want to ensure the system under test calls a certain method from a single thread,  in other word we want the mock to explicitly require single thread access to certain methods. This could happen for example when we are mocking some UI components, but there is such situations every time the object we are mocking is intrinsically non thread safe and the SUT is multithreaded. So I extended the MoQ fluent language from the internal and I obtain something like…  the example below:


So in the setup phase we declare a method ( or a setter, or a getter, as usual ) to be SingleThread(). This yield a mock throwing when the method is called from a different thread from the one which did the setup.

If you are happy with this modifications ( you would for sure find helpful the thread safety by its own ) feel free to check out my code fork on GitHub, in any case I’m trying to have that modification pulled from the main stream.

Wednesday, 21 March 2012 15:53:26 (GMT Standard Time, UTC+00:00)  #    Comments [0] - Trackback
C# | CodeProject | MoQ

# Thursday, 15 March 2012

I’ve already talked about the simple contract checking library here. I did a little improvement that allow us to write such a code:

public void DoSomethingWithCustomMessage(string arg1)
            Contract.Expect(() => arg1)
                .Throw<Exception>("I'm unhappy to see that {0} is null")


Note than {0} is replaced with the name of the argument so the library is refactoring friendly and DRY. The only restriction is that the exception type must support a constructor with a single string argument. Obviously .Throw can be used fluently after each all Expect(). As another minor improvement, even the .Expect can be called now fluently more than once, so multiple check can be done fluently too. The entire repository is on Bitbucket here. In order to use the library you just have to include the single file, but is better to point the repository since the file version can change in subsequent releases.

Thursday, 15 March 2012 16:16:42 (GMT Standard Time, UTC+00:00)  #    Comments [0] - Trackback
C# | CodeProject

My Stack Overflow

Send mail to the author(s) E-mail

profile for Felice Pollano at Stack Overflow, Q&A for professional and enthusiast programmers
About the author/Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2017
Felice Pollano
Sign In
Total Posts: 157
This Year: 0
This Month: 0
This Week: 0
Comments: 124
This blog visits
All Content © 2017, Felice Pollano
DasBlog theme 'Business' created by Christoph De Baene (delarou) and modified by Felice Pollano
Nike Winkels Nederland Outlet Nike Nederland Store Outlet Nike Nederland 2015 Outlet Nike Outlet Online Nike Sneakers Outlet