August, 2014

...now browsing by month

 

good reference on abstract class vs interface

Friday, August 29th, 2014

This reading really makes it crystal clear about the similarity and difference between an abstract class and an interface http://msdn.microsoft.com/en-us/library/scsyfw1d(v=vs.71).aspx and it is easy to read. Here are the key points I took away from this casual reading:

  • Abstract class and interface both are to be inherited to be useful – this is one similarity.
  • The differences are many:
    • One subclass can inherit only one abstract class but can multiple interfaces or one base class + one or more interfaces.
    • Abstract class can have implementations but Interface does not have implementation.So if you want to have complete control of how a method is implemented, you build an abstract class to include it; otherwise, use interface to allow the inheriting class (subclass) to implement their own; in this sense, an abstract method in an abstract class is acting like a public method in an interface – they both must be implemented or overriden in a subclass.
    • An interface can be passed as an argument or initiated as an object such as:
       void GetEmailTemplate(ITemplate t) 
                     { //implementation ;
                     } 
      
       or  void SaveEmailTemplate()
      {
             IEmailTemplate t=new EmailTemplateClassThatInheritTheInterface(); 
             t.DoSomethingThatIsContractedToDoInTheInterface();
      
      
      }
      

      But an abstract class has no such freedom.

    • Interface has no knowledge and control of how its contract methods will be implemented; only thing for sure is all its public methods must be implemented in the subclass. If viewing the interface as a universally observed law – “crimes must be punished”, then while different countries must enforce the punishment but implementation of punishment can vary greatly, such as Singapore can canning you for spitting on street while other country just jails you even you murdered people, like in US.
  • So, in designing a solution, if I want to have some control over certain core operations of the classes, I would wrap those base methods with my desired implementations in an Abstract class so all the subclasses inheriting from it will automatically have my implementations, no kidding around.
  • And if I want to allow certain methods to be implemented in a subclass that I don’t give a damn, then I will add a few virtual methods in my abstract class – that give me some of those Interface power and flexibility; virtual can have some basic implementation for subclass to override with its own implementation or use directly without second thought.
  • Another concept is an Abstract method, what about that? Well, think this way, you want to force a subclass that inherits your abstract class to behave like inheriting from an interface (but you don’t want to use an interface because you want to have a tight grip on certain base implementations), what will you do? Yes, an abstract method – there is no implementation in base class but subclass must override it with its own implementation.

 

 

 

The bad (might be good to some) attribute introduced in MVC4 – [InitializeSimpleMembership]

Thursday, August 21st, 2014

Yesterday I deployed a MVC4 app to Winhost and got this error below when I clicked on “Log In” or “Register”, which I didn’t when deployed to local IIS.

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)

I had seen such error before; mostly the error was due to some misspelled SQL server name or firewall blocking remote access, etc. I checked my SQL server connection strings for both SqlClient and Entities Framework model and were able to connect to the remote SQL db hosted at Winhost. When I submitted a support ticket to Winhost tech team, their server side log showed that my app tried to connect to a SQL Express instance which they don’t support. How strange was that? I do not use SQL Express and my database which contains the ASP.Net Membership objects resides on a full version local SQL Server, not Express. There is no place in my web.config that has anything to do with SQL Express instance. So I examined the Controller codes where the Log In link is clicked; here it was, the new “InitializeSimpleMembership” attribute on the AccountController class which was created automatically by my selecting the “Internet Application” MVC4 project template. This was something new introduced by MVC4 team at Microsoft, where a bunch of genius are always trying to come up with some dummy robot codes to  make everything so automatic – by “simply” looking for a SQL Express db to initiate the Membership provider for Web.Security; this “InitializeSimpleMembership” attribute, as it turns out, was the only culprit for all these non-simple headaches when you deploy your site to hosting server that usually do not support SQL Express. And there was no warning or error when I used the Publishing wizard from VS2012 to deploy the site to Winhost.

The fix? Simply commented out the attribute, as shown below,and re-deployed to Winhost; then everything works!

[Authorize]

  //[InitializeSimpleMembership]
    public class AccountController : Controller
    {
        //
        // GET: /Account/Login

        [AllowAnonymous]
        public ActionResult Login(string returnUrl)
        {
            ViewBag.ReturnUrl = returnUrl;
            return View();