Data Warehouse Company, Custom data warehouse development, data warehousing, custom data warehousing, cube development

This is a great website about custom data warehouse companies.
Data Warehouse Company, Custom data warehouse development, data warehousing, custom data warehousing, cube development

Custom Sharepoint Application Development

Check out this new site for custom sharepoint development:

Custom Sharepoint Application Development

LINQ code to edit vs insert new records

Another post in the series: Things other developers do that drive me crazy

Here's an example of someone else's code that I'm currently working with:

PRODUCTGROUP AddProductGroup;

if (ddlProductGroups.SelectedIndex == 0)
{
AddProductGroup = new PRODUCTGROUP();
AddProductGroup.DateCreated = DateTime.Now;
}
else
AddProductGroup = ProductManager.GetProductGroupByID(Convert.ToInt32(ddlProductGroups.SelectedValue));

AddProductGroup.DateModified = DateTime.Now;
AddProductGroup.LastUpdatedBy = UserProfile.GetUserGuid(User.Identity.Name);
AddProductGroup.ProductGroupName = txtProductGroupName.Text;

if(ddlProductGroups.SelectedValue == "0") Data.CurrentContext.PRODUCTGROUPs.InsertOnSubmit(AddProductGroup);
Data.CurrentContext.SubmitChanges();

ProductGroupID = AddProductGroup.ProductGroupID;

Ok it's not terrible. But there is one line that seriously bugs me. It's this one:

if(ddlProductGroups.SelectedValue == "0") Data.CurrentContext.PRODUCTGROUPs.InsertOnSubmit(AddProductGroup);

This code is written to handle new records being inserted and existing records being updated based on what is selected in the drop down list ddlProductGroups. Why do we need to check if the ddlProductGroups.SelectedValue is "0"? In the beginning of the code block there is already this:

if (ddlProductGroups.SelectedIndex == 0)
{
AddProductGroup = new PRODUCTGROUP();
AddProductGroup.DateCreated = DateTime.Now;
}

So just change it to this:

if (ddlProductGroups.SelectedIndex == 0)
{
AddProductGroup = new PRODUCTGROUP();
AddProductGroup.DateCreated = DateTime.Now;
Data.CurrentContext.PRODUCTGROUPs.InsertOnSubmit(AddProductGroup);
}


There, now you don't need that subsequent "if" statement. You can instance a new PRODUCTGROUP object, set the date created, and tell LINQ to InsertOnSubmit all in the same block of code.

Customer Relationship Management Software

Just launched a new website for Customer Relationship Management (CRM). We build custom CRM software for companies in any industry.

Customer Relationship Management Software

NJ Web Development, Custom Web Development, Custom Software Development, Business Edge Services

NJ Web Development, Custom Web Development, Custom Software Development, Business Edge Services

Limit use of member variables in code-behind

I frequently come across code that looks something like this:

private int memberVariable;

private void StartHere() {
memberVariable=1;
}

private void RunFirst() {
memberVariable=2;
}

private void PrintResult() {
int result = memberVariable*4; //<--error on this line for example
}

Let's say there is an error on the line marked with the comment above. In troubleshooting the issue, it might be helpful to know what the value of memberVariable is. If I look at PrintResult(), I see a variable named "result" which is being defined as an int. But then I see it using "memberVariable" which is defined outside of PrintResult(). Since I didn't write this code, it is difficult for me to know what exactly memberVariable is at the time PrintResult() gets called. Did StartHere() get called before PrintResult()? Did RunFirst() get called? If both were called, which ran last?

It is much more desirable NOT to declare variables outside of the methods they are being used in. Of course there are some situations where you must do this kind of thing, but for the most part, you should be able to use variables inside methods by PASSING them to the method instead of relying on them being instanced and valued at some point before our method being called.

Stuff that other web developers do that drive me crazy

Lately we've had a lot of custom web development projects where we are inheriting someone else's code, and we need to take over the project and make updates to it. It's been a bit crazy lately, and sometimes a bit frustrating. I just wanted to start keeping a log of things that other developers do that drive me crazy.

1. Having a method call another method when that's it's only purpose, and the other method isn't called from anywhere else. Something like:

public void RunCode() {
DoSomething();
}
public void DoSomething() {
int a=1;
int b=a+1;
..whatever...
}

If DoSomething() isn't called by anything else, what is it's purpose? Just put everything under RunCode(), no?

2. Making a database call on each row of a repeater (or datalist or gridview or whatever) Something like:

public void MyDataGrid_ItemDataBound(object sender, EventArgs e) {
Label lblFirstName = (Label)e.Item.FindControl("lblFirstName");
int userid = Convert.ToInt32(MyDataGrid.DataKeys[e.Item.ItemIndex]["userid"]);
Member oMember = new Member(userid);
lblFirstName.Text = oMember.FirstName;
}

This might look ok on the surface, but how are we populating the oMember object? We're making a database call right there in the constructor. This is not good practice because as the datagrid grows, every time it loads it will make a database call on every row. If you have many users hitting this page, your database activity could skyrocket unnecessarily. You should try to bind elements of your repeaters and datagrids to a single query that returns all the data you'll need to populate all of the fields, and don't make any database calls in repeating events.

3. SQL Cursors. Ugh, this is a real sore spot for me. I see so many developers using cursors, and 90% of the time, I am able to rewrite the query using a set-based query. I don't know why people use cursors so much. If you are writing a SQL cursor, you should just think it through and see if you can use a set-based query instead.

4. The Session object. This is perhaps the most widely abused object in all of web development. Every book I read about ASP.Net has at least a whole chapter devoted to the session object, its no wonder so many people use it. For one, using the session object causes the web server to have to allocate memory to EACH user who is using the website. When building web based applications, you want to minimize the amount of resources each user takes up on your web server so that you can grow without bringing the server down. People needlessly store variables in the session object so they can use them later instead of intelligently designing their application in such a way so as not to need the session object. On all of our web servers, we have the session object turned off right in the IIS settings and in 12 years I've never had the need to use the session object for anything.