2
\$\begingroup\$

Below is the class which I am using to fill multiple DropDowns on ASP.NET Page Load event:

public sealed class getBlocks
{
    public getBlocks(DropDownList dropDownName, string districtId)
    {
        returnBlocks(dropDownName, districtId);
    }

    public void returnBlocks(DropDownList DropDownName, string DistrictId)
    {
        var DB = new PetaPoco.Database("cnWebDems");
        string Query = "SELECT distinct blockname, blockid FROM hab_master WHERE distid = '" + DistrictId + "' ORDER BY blockname";
        var result = DB.Fetch<hab_master>(Query);
        DropDownName.DataSource = result;
        DropDownName.DataTextField = "blockname";
        DropDownName.DataValueField = "blockid";
        DropDownName.DataBind();
        DropDownName.Items.Insert(0, "-- Select --");
        DB.Dispose();
    }

Suggest further improvements.

\$\endgroup\$

1 Answer 1

3
\$\begingroup\$

Firstly, data access should be separate from your UI logic. Certainly create a new layer, where you'll manage CRUD operations.

Secondly, I'm not really fond of your naming convention of classes. Even though it may be a subjective matter, many people tend to use capitalized names for classes and certainly not using words like "getBlocks". This isn't a name for a class, that's a name for a getter method.

Thirdly, you're dealing with your parameters the wrong way, at least in my opinion. I believe it would be more appropriate to have private fields of type DropDownList and String, populate them in the constructor and then just use these private variables (and/or properties, depends on your needs) instead of specifying parameters for the method itself. Seems more OOP to me that way. Otherwise I don't really see a reason why not just create a helper class with a static method you'll call whenever needed, without the need to instantiate the class itself.

Another thing to consider - usually it's better to use an using statement instead of manually calling Dispose method.

Edit based on the comment:

1.) example using private fields

public sealed class Blocks
{
    private DropDownList _ddList;
    private int _districtId;

    public Blocks(DropDownList dropDownList, int districtId)
    {
        _ddList = dropDownList;
        _districtId = districtId;
    }

    public void PopulateDropDownList()
    { 
        var results = MyDbAccessClass.GetBlocks(_districtId); 

        _ddList.DataSource = results;
        _ddList.DataTextField = "blockname";
        _ddList.DataValueField = "blockid";
        _ddList.DataBind();
        _ddList.Items.Insert(0, "-- Select --");
    }
}

2.) example using static method

public sealed class MyHelperMethods
{
    public static void PopulateWithBlocks(DropDownList ddList, int districtId)
    {
         var results = MyDbAccessClass.GetBlocks(districtId); 

        ddList.DataSource = results;
        ddList.DataTextField = "blockname";
        ddList.DataValueField = "blockid";
        ddList.DataBind();
        ddList.Items.Insert(0, "-- Select --");
    }
}

Hope you get the idea...

\$\endgroup\$
7
  • \$\begingroup\$ I appreciate your comments. Can you please illustrate third point with little code. \$\endgroup\$
    – RPK
    Commented Jul 6, 2012 at 8:40
  • \$\begingroup\$ @RPK, please see the updated answer with examples. Hope it helps. \$\endgroup\$
    – walther
    Commented Jul 6, 2012 at 12:01
  • \$\begingroup\$ I avoid static methods because they create problems in a concurrent environment. Will your static method work in such environment? \$\endgroup\$
    – RPK
    Commented Jul 6, 2012 at 16:56
  • \$\begingroup\$ Static variables are dangerous in asp.net, that's true, but static methods should be perfectly ok, especially helper methods like this. I've been using similar methods in asp.net on various shared webhostings without any issue for quite some time. If you're working with some kind of multi-thread application or with an application with its data being constantly edited by multiple users, you still need to apply some lock mechanism that will prevent possible problems with deleting, inserting and updating the data. \$\endgroup\$
    – walther
    Commented Jul 6, 2012 at 17:33
  • 1
    \$\begingroup\$ @RPK, not sure what caused your problems back then, maybe you should post that code in another question, but I've made some research on the Google and made some tests by myself, resulting in the same answer - static methods aren't a problem unless you use static variables. Static methods are thread-safe. The biggest issue about static methods is unit testing, but that's a different matter... If your GW started to show results of another user's ddlist, it implies you used static members/variables/properties, but the method itself probably wasn't the problem... \$\endgroup\$
    – walther
    Commented Jul 7, 2012 at 14:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.