CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Ranjan Sakalley

February 2005 - Posts

  • Why should I use .net

    Yesterday, I was asked to train a set of freshers on what .net Fx provides, about CLR, and other things .net. About half-way through the second session, when I was delightfully talking about Garbage Collections and Finalization Queues (after a class on telling them the brokerage mechanisms, Virtual Machines, what was wrong with previous frameworks, what Java brought into picture, and now what .net has helped us with), one guy says 'Why should I use .net?'.

    I took around half-an-hour to tell the guys why would one, poking into topics like drivers, winforms, html engines ( the Framework class library reuse was what I was talking about) and why shouldn't we be writing them and be worried about our program logic. Then I went over to Component Based Programming, COM, managed memory etc. Still confused.

    Problem ? Yes, the guys have never ever coded commercially. They are great at writing algos in C, math, but they have never written one piece of code that somebody else has used. I cannot blame it on the education system, because I came out of it once, fortunately for me, there was some time with C at college writing GSM algos, and at work Delphi/people who had worked with it, to know what a relief Java/.net is.

    But these guys dont even know what a customer would expect from their output. They wouldn't think twice before writing their own spell-checker component(would take more than a man-month) insted of reusing the one that comes with Office (would take an hour). They don't know the pains of memory management, using C to create a form etc. I just wanted to nullify the current training session, and start the whole process something like this-

    1. Ask them what do they expect from a mail client. Show them Outlook, and ask them if they wanted something more from it. Before teaching them how to code, this will atleast lead to these guys knowing things from a customer's perspective.

    2. Ask them to write a simple Outlook sidebar control using C (which they are good at) , after a day or two, cut-short their development, and show them how to do this with Devexpress or Infragistics in a minute or two. Mind that freshers get attracted to UI invariably. Thats the only experience that I have in this process.

    3. Give them a component after this, written in VC++, and ask them to use it in VB without using COM, make them appreciate COM, and then wreck the ship after telling them how better an upgrade .Net is. (Don Box, 1st Chapter)

    4. In any of these cycles, show them a menory management issue and tell them about managed environment.

     After attracting these guys to (if i am able to) I would basically move away, and let them explore, with an assignment to implement some Data Structures etc. for a week. So a two week pre-training schedule is what I was looking at. Costly, but then I dont know about a book that will make them understand "why to use .net?'. Can you point me to some, so that we can cut-short this fortnight long build-up?
  • .Text and need to indicate reposts before publishing

        After joining such a distinguished set of .net bloggers, one's first fear is not to repost on something that's already been discussed or written on by somebody great.
        My idea of solving this issue is to basically put a hook on the POST button, find out all posts that correlate to the post subject ( trying this out with the formatted body would be really messy) from the cs_Posts table ( Community Server 1.0 DB) and show it to the user on a grid, with links, so that the blogger knows about related posts.
        I know what you are thinking. Wouldn't it be better is we could have a search functionality? This would probably help a visitor find out things too. Wouldn't be too hard to implement I guess, if we have Full-Text Indexing services installed on the DB server. Good idea?
    Posted Feb 23 2005, 07:35 AM by rsakalley with 9 comment(s)
    Filed under:
  • NUnit and automatic method input parameter verification

    Almost all methods depend on one or more input parameters. To verify each and every one of these parameters, for boundary conditions, nulls and such generic cases, becomes an overload, for each method in a class. It also leads to writing repetitive test cases to check the same type of an input parameter. For example, consider the following method 
     

            public int FirstCheck(int first, int second)
            {
                
    return first + second;
            }

     

    To check both the integer variables for boundary conditions, negative values etc. using NUnit would require writing repeated test cases for each one of these variables. Similarly with strings, Dates and other value types. For reference types, a test for nulls is required. Writing test cases becomes a tedious task, and therefore a developer, may miss these cases. To solve this problem, I have tried to create an attribute to add to the existing ones in NUnit, which can be placed over a class. The NUnit core identifies this attribute, and redirects it to a custom test case builder which is added to create and run test cases for boundary values for value types, and nulls for reference types. An input to this attribute is an exception type, which is the expected exception when the test fails. Lets consider an example,

     

    [TestParams(typeof(InvalidOperationException))]
        
    public class TestParamsTester
        {
            
    public int FirstCheck(int first, int second)
            {
                
    return first + second;
            }

            
    public string SecondCheck(int first,int second)
            {
                
    return first.ToString() + second.ToString() ;
            }
        }

     

    The attribute placed over the class implies that NUnit should test each and every parameter for all methods in this class. Also, when a test fails, NUnit expects an InvalidOperationException. When the class is loaded using NUnit (for better understanding, the NUnit-GUI is used here), the methods are added as test cases

     


     

     

    When the test cases are run, we get the following results

     


     

    With such a functionality provided by NUnit itself, a user does not need to use any new software to do such an automatic verification (just changing 2 dll's would enable NUnit to support this functionality). I am currently extending this verification process to have a user specify custom boundaries and cases using an XML file. Also, instead of creating one test case per method, all boundaries have a separate test case, for the end-user to immediately identify the failing verification.

    What do you think of this idea? And yes, let me know if you have any suggestions.

    Posted Feb 21 2005, 12:41 AM by rsakalley with 2 comment(s)
    Filed under: ,
  • Developing a multi-template website.

    While developing a product that automates the creation of a web-site, an eCommerce one or else, you need to know that having a set of similar looking web-sites is not what your customers would want. When B uses your product to create his front-end on the web, he would want it to be different from the one A created using your product. A very simple solution to this is to use style sheet based web-pages.

    But there are cases where a mere style change will not suffice. You may need to re-design the layout the pages separately, which means that you need to have multiple front end support for your business logic. This also means that if not designed properly you will end up copying calls to your “Business Logic” on every page’s code behind class; maintenance issue.

    I tried this iterative design process for a while, and just wanted to validate it with you guys.

    1.      Consider creating a separate object for each page. 
        The calls to a business server are made from another object. Let’s say, you are designing a Login page, in three templates. Instead of copying your calls to these three web-pages (or set of user controls if you like), delegate such calls to another class, say PoLogin. Instantiate this object in each of these 3 (or more) pages, and make a call to this method, sending it the Request. Something like this -
    The PoLogin object has a
                                  DataSet GetData(Request _request, <other configs/params> ) {…..}

    which there page instances will call.

    2.      The above design, though abstracts the calls from each page, has a flaw. There is a need to instantiate the PoLogin class in each template. So you will end up writing the instantiation code in all the pages. To refine this design, try creating a LoginBase (.aspx) page, which will instantiate the PoLogin object. Each of the template pages, will in turn extend this LoginBase page. 

     A protected instance of the PoLogin class can thus be used in all the pages.

    3.      This design is very good for a single web-page. Imagine having a set of 60 web-pages, each page having such a set up. This design can be further refined in such a case, bearing in mind that the Po<page> classes is basically going to fetch you data, if designed properly, with just a single method call. This leads to an easy conclusion, Factory. 
    Imagine that you have 3 web-pages now, Login, Items and Categories. This will mean that you have 3 classes, PoLogin, PoItems and PoCategories which have an IPageObject contract to their instantiators. IPageObject has a single public method, with a comprehensive set of inputs that are common to all calls to get data, irrespective of the web-page in question. Instead of having each base web-page (LoginBase, ItemsBase or CategoriesBase) having the knowledge of which Page Class to instantiate, abstract this using a factory (
    http://www.dofactory.com/Patterns/PatternAbstract.aspx).

    4.      Further refinement, the declaration of a IPageObject instance done in a PageBase class, which will be extended by all the pages
     
    and these pages will in turn instantiate the respective Page Class using the factory.

    Of course there may be better ways to do this, and I would really appreciate comments for refinement.

      

    Posted Feb 10 2005, 12:13 AM by rsakalley with 7 comment(s)
    Filed under:
  • partial types revisited

    Yesterday, I wrote about why I think partial types were redundant. I apologize for jumping the gun there without enough research required to make such a comment, and held my opinion (a bit adamant on my part) even when Frans, Wesner and others commented saying its a nice feature to have. Since then, I have tried to learn more about this construct, the help it provides with code generation and more, to a developer.

    As Frans mentioned

     If some team goes bezerk over this feature, I think it's more a problem related to management than to  the developer. I mean: what's so hard to understand about:
    - one part is for code generation
    - one part is for extension through custom code.

    Basically, when I was was busy mentioning XAML/ASPX + inheritance, I forgot to see the manageability issues from a POV other than mine. Lately I have been negative, its the time to get into a positive mindset.

    So, for a team that knows their bit, and don't mess up too much, here are some points.

    • Separating generated (and regeneratable) code from the custom logic is a plus. I got my mistake right after seeing a set of autogenerated Data Access Layer classes, where the generator provided only CRUD functions, and no functions for running stored procs, mainly because it did not generate the stored procs and views. Writing such functions elsewhere (in another class) would harm our purpose of creating a class that works over Data Access on a table. I think partial types provide a good scene here.
    • Consider ASP.Net. I have worked on a product that creates an eCommerce website, given a database. We wanted to give away a set of heavy themes with these web-sites, we had to go for a page class for each web-page.

      Because the aspx pages and their related javascripts, controls, structure of user controls were so different, we decided to have a separate aspx + code behind class for each web-page for each logical web-page in all templates. The code behind classes for a page in all templates referred to a single page class. With partial classes, there is no need of such a design, or should I say, its inherent. There are some issues btw, when you move up from v1.1 to v2.0(beta and +)  -

      1. There will be two files to manage. The code behind class, as with all generated classes, will be divided into 2 partial classes. One with custom logic, the other with the declarations (can be private now). So if you are upgrading, remove the declarations from the code behind class, the IDE will generate these in a partial class.
      2. The web-page/aspx class will inherit the consolidated class(the compiler will consolidate both/more partial classes) at runtime, and hence work similarly to the way it works in v1.1. New command line compiler.
      3. There are attributes which you can set to keep the process the way it works in v1.1. Also, if you have your v1.1 code behind class compiled in a different assembly, you can keep it that way.

    • Windows forms - By adding one more function call, to a private method in the same object, you can actually separate, like asp.net, the windows design from processing logic(calling BL functions etc.), so its easy for a team to separate work on UI logic from UI design. I know this must have been done before by somebody, by inheriting from a form that has protected functions/something like a page class above, its just that after compilation, it will be a call to private functions in the same object.

    OK, so this was the part where I came to know how to manage stuff using partial types, and use this construct constructively. I still had my doubts as to what lead to its inclusion. I asked Craig Andera, and am very grateful that he replied, even though I have never had any communication with him before, and I am more or less an anon. This is what he had to say-

      There are many problems with inheritance. For one, it forces you to use up your one and only base class somewhere, which isn't necessarily always what you want to do. It also means you don't get access to private member variables, which, in some codegen scenarios, is a useful thing. But really, inheritance is just too big a hammer to solve this problem: designing classes correctly for inheritance is really, really complicated, when all you really want to do is just to generate some code and then add or alter one or two methods.

    Hopefully, I have apologized enough. 

     

  • On partial types in C# 2.0, and other redundancies

    For some time, I have been thinking about language contructs that are a pain when it comes to code management, readability and more often than not inculcate poor coding habits amongst developers.

    • Nested classes -I have never found a valid reason to use them. I really feel that an inner class is something that looks better in books and asked in interviews. I haven't noticed a single instance where you *really* need a nested class. I am sure there are better, much more readable ways to code.
    • params - One can easily go with a collection/DTO which holds the required parameters. It is a just redundant. If I do not have the exact number of parameters that a function I write expects, I would use an array, like its done in a BeginInvoke call for a Control instance
      public virtual IAsyncResult BeginInvoke(
         Delegate method,
         
      object[] args)

         Morover, If I ever use more than 10 input ( + output ) parameters, and not think about a DTO, I would better stop programming and start afresh on alchemy (not a bad idea either).

    There is goto but I will never let go of it, reminds me of better times ( jmp is still there at the top, and will remain), even though I prefer not to use it.  

       Now with 2.0 comes another new one. partial classes. The documentation more than tries to please the reader and clearly indicates that this is really needed for Code generation, Windows forms underlined. There is a problem here, not only is it *not needed*, it is powerful enough for a set of developers to develop a bad habit, rather than code. Ofcourse there are better ways to hide generated code, XAML +/ inheritance (as with ASP.Net web-pages) for designs atleast, or arent't they?

    Two developers maintaining a class is a maintainance problem, three is a disaster. And partial interfaces ?

     

    Posted Feb 01 2005, 12:57 AM by rsakalley with 18 comment(s)
    Filed under:
More Posts

Our Sponsors