Linq's syntax symmetry with Postgres

Can't help but notice, Linq multiple condition has more affinity with Postgres flexible syntax:

from c in Customers
join o in Orders on new {c.CompanyID, c.CustomerID} equals new {o.CompanyID, o.CustomerID}

Postgresql:

from Customers as c 
join Orders as o on (c.CompanyID,c.CustomerID) = (o.CompanyID,o.CustomerID)

Bye bye attributes-based APIs! Hello fluent APIs!

Cool kids are not doing this style of programming anymore:

public class Flight
{
    [DisplayWidth(200)]
    [FinderController(UseFinder=typeof(CountryFinder), SelectedID="SelectedCountryCode")]
    public string CountryCode { get; set; }
    
    [DisplayWidth(200)]
    [Color(Color.Blue)]
    [FinderController(UseFinder=typeof(CityFinder), SelectedID="SelectedCityID", CascadingField="CountryCode")]
    public int CityID { get; set; }
    
    
    [DisplayWidth(100)]
    [Spinner(From=1,To=30)]
    public int StayDuration { get; set; }
}

Not that there's something fundamentally wrong with that, however, with the confluence of the language's new features and the desire of many programmers to have their code be free from the clout of the tyrants, many programmers nowadays are realizing that their codes can be geared towards using plain classes. Classes that are not encumbered with infrastructure concerns, classes that best mirror the problem domain, classes that are just plain. Hence we just want the following class above to be like this now:

public class Flight
{
    public int CountryID { get; set; }
    public int CityID { get; set; }
    public int StayDuration { get; set; }
}

For example, if you used that class in Entity Framework yet you want to re-use that class in other ORM(say NHibernate), you won't want any EF infrastructure concerns be carried over from EF to NHibernate. You wanted your classes be in POCO form so you can re-use those classes in any way you deem them they fit.


Given that we strive towards writing POCO classes now, how can we deliver the input functionality around your domain classes without tainting them? One way is to use XML, but as any discerning programmers knows, XML-based APIs are going the way of the dodo now


With the confluence of C# 3's Expression and fluent programming, we can come up with an elegant way to map the domain classes to input. We can avoid XML and attributes-based API altogether.


But before we head to that, there's something inelegant with attributes-based APIs that needed be pointed out. It promotes social-based programming, it's good to be social, with code however, it's a different matter altogether. With social-based programming, every time you need to know about something, you often have to ask someone for their expertise. With attributes-based API, you'll often find yourself asking someone if there's already an API that does this or does that. As attributes are not discoverable, you can't quickly know which attribute needed be used for certain functionality, thus oftentimes you need to ask a colleague. This is not good for an industry such as ours, our industry is prone to bus factor. Whom to ask if the experts are not around? Though some might suggest you read the manual, but as we all know, most programmers don't read manuals


Another bad thing with .NET attributes is they are designed to be simple, i.e. you cannot use generics on it. Some just contend with the fact that they can only fashion stringly-typed API on top of it, e.g.

[FinderController(UseFinder=typeof(CityFinder), SelectedID="SelectedCityID", CascadingField="CountryCode")]
public int CityID { get; set; }

With stringly-typed API, it's not readily apparent from where you should get your CascadingField, is it something that is inside the CityFinder class? or is it in the Flight class?


However, with C# 3's Expression + fluent programming, you can make your API more discoverable, you'll be able to discover things by yourself fairly automatically.





So here's how we can make our input API be more discoverable with the use of C# 3's Expression and fluent programming.

public class Flight
{
    public int CountryCode { get; set; }
    public int CityID { get; set; }
    public int StayDuration { get; set; }
}


public class FlightInput : InputMap<Flight>
{
    public FlightInput ()
    {
        Input(x => x.CountryCode) // Use C# 3's Expression
            .DisplayWidth(200)
            .Color(KnownColor.Blue)
            .UseFinder<CountryFinder>().SelectedID(x => x.SelectedCountryCode);

        Input(x => x.CityID)
            .DisplayWidth(200)
            .Color(KnownColor.Blue)
            .UseFinder<CityFinder>().SelectedID(x => x.SelectedCityID).CascadingField(x => x.CountryCode);

        Input(x => x.StayDuration)
            .DisplayWidth(100).Color(KnownColor.Green)
            .UseSpinner(1,10); 
    }
}

With fluent-based API, you can check where the CountryCode on CascadingField come from(F12 or Ctrl+B(if using Resharper)). And while writing the CascadingField, the IDE can show you where the  CascadingField is getting its value from:

That's it! that's how elegant fluent-based API is! It keeps your domain classes in their pristine form (termed as POCO if you may), making your domain classes be very amenable to be re-used on many parts of your system.


One more thing, your code is refactoring-friendly with Expression and fluent-based API.


Sample Fluent API barebone code: http://www.ienablemuch.com/2012/12/sample-fluent-api-barebone-code.html


Happy Coding! ツ

ASP.NET MVC returned type discipline

A few times I'm seeing this in code...

public ActionResult GetSoap()
{
    return Json(new Soap { Name = "Tide", Feature = "With Calamansi" } );
}

...instead of the following one in which you can easily infer the code's intent:

public JsonResult GetSoap()
{
    return Json(new Soap { Name = "Tide", Feature = "With Calamansi" } );
}

That's deliberately leaking an abstraction. A devil's advocate would suppose you are just showing off your deep knowledge on ASP.NET MVC's object hierarchy, that you know that JsonResult derives from ActionResult, thus you can just make every MVC actions' return type an ActionResult. Well guess what, everything derives from object anyway, hence just make everything return an object and it will still compile and run:

public object GetSoap()
{
    return Json(new Soap { Name = "Tide", Feature = "With Calamansi" } );
}

The problem with that approach(and the ActionResult code above for that matter) is you need to cast the returned results to its actual returned type(JsonResult) when you need to do TDD on that method. Hence warranting an explicit casting.

[Test]
public void SomeTest()
{
    // unnecessary casting
    JsonResult r = (JsonResult) GetSoap(); 
    
    Soap s = (Soap)r.Model;    
}

Whereas if you declare the MVC method to return its actual returned type, i.e. JsonResult, you don't need to do extra casting when doing unit test on it:

[Test]
public void SomeTest()
{
    JsonResult r = GetSoap(); 
    
    Soap s = (Soap)r.Model;    
}

Giving the controller action's return type an specific type makes the code intent clearer

Happy Coding! ツ

We are at the mercy of language designers

using System;

namespace Craft
{

    public delegate string Greeter(string s);
    public class HeyAttribute : Attribute
    {
        public Greeter GreetAction { get; set; }
    }


  
    // Strongly-typed mechanism on attribute is no joy in C#, it's not
    // possible.  C# language designers reduces the attributes "complexity" :
    // http://stackoverflow.com/questions/294216/why-does-c-sharp-forbid-generic-attribute-types

    [Hey(GreetAction = Mate.Yo)] // This will not compile, despite the simplicity
    public class Test
    {
    }



    public class Mate
    {
        public static string Yo(string s)
        {
            return "Hello " + s;
        }
    }


    class Program
   {
        static void Main(string[] args)
        {           
        }
    }

   
}



   

Banker's Rounding

.NET uses banker's rounding by default, not the common rounding.To override it, specify MidpointRounding.AwayFromZero(aka common rounding) on Math.Round

That is, the presence of 0.5 in a number won't automatically round the number up, rounding up is balanced between odd and even numbers.

When you use Math.Round ​on a number with extra 0.5, the even numbers are rounded down, odd numbers are rounded up.

To illustrate "banker's rounding" (.NET default rounding is banker's rounding. If you want to be explicit about it, specify MidpointRounding.ToEven on Math.Round) :

static void TestBanker()
{
    Console.WriteLine(Math.Round(0.5)); // 0
    Console.WriteLine(Math.Round(1.5)); // 2
    Console.WriteLine(Math.Round(2.5)); // 2
    Console.WriteLine(Math.Round(3.5)); // 4
    Console.WriteLine(Math.Round(4.5)); // 4
    Console.WriteLine(Math.Round(5.5)); // 6
    Console.WriteLine(Math.Round(6.5)); // 6
    Console.WriteLine(Math.Round(7.5)); // 8
    Console.WriteLine(Math.Round(8.5)); // 8
    Console.WriteLine(Math.Round(9.5)); // 10
}

To illustrate "common rounding" (.NET parameter is MidpointRounding.AwayFromZero)

static void TestCommon()
{
    Console.WriteLine(Math.Round(0.5, MidpointRounding.AwayFromZero)); // 1
    Console.WriteLine(Math.Round(1.5, MidpointRounding.AwayFromZero)); // 2
    Console.WriteLine(Math.Round(2.5, MidpointRounding.AwayFromZero)); // 3
    Console.WriteLine(Math.Round(3.5, MidpointRounding.AwayFromZero)); // 4
    Console.WriteLine(Math.Round(4.5, MidpointRounding.AwayFromZero)); // 5
    Console.WriteLine(Math.Round(5.5, MidpointRounding.AwayFromZero)); // 6
    Console.WriteLine(Math.Round(6.5, MidpointRounding.AwayFromZero)); // 7
    Console.WriteLine(Math.Round(7.5, MidpointRounding.AwayFromZero)); // 8
    Console.WriteLine(Math.Round(8.5, MidpointRounding.AwayFromZero)); // 9
    Console.WriteLine(Math.Round(9.5, MidpointRounding.AwayFromZero)); // 10
}

Other good explanations:

http://blog.troyd.net/Bankers+Rounding+Vs+Common+Rounding+In+NET.aspx

http://stackoverflow.com/questions/311696/why-does-net-use-bankers-rounding-as-default