Check out this new site for custom sharepoint development:
Custom Sharepoint Application Development
Friday, October 29, 2010
Wednesday, October 20, 2010
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:
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.
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;
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.
Saturday, October 16, 2010
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
Customer Relationship Management Software
Thursday, October 14, 2010
Monday, August 9, 2010
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.
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.
Tuesday, June 2, 2009
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.
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.
Thursday, May 21, 2009
Classic ASP vs. ASP.Net
Just what is the difference between the deceptively similar technologies of ASP and ASPX? What does it say about a website that still uses ASP pages versus one that uses ASPX pages?
In speaking with people every day, it seems this is a pretty common point of confusion. Most people who aren’t developers figure that since “ASP” is so close to “ASPX” that the differences between the two technologies can’t be all that extensive. After all, ASP is technically 75% of ASPX, so upgrading to ASPX will only give 25% more in features or capabilities. When I tell them that the differences between the two technologies are pretty vast, they are often quite surprised.
From a user’s perspective, it is hard to make the differences obvious. After all, a web page that ends with an .asp extension can look pretty similar to a web page that might end with an .aspx extension. The two pages might even have the same functionality and operate in much the same way. So then what is the difference, and why does anyone care?
Back in 1996 (or thereabouts) when Microsoft came out with Active Server Pages (ASP), the web was still in its infancy. ASP was a new technology which solved a lot of the limitations of HTML and CGI, and was very easy to use. Because of this, ASP caught on and became hugely popular. ASP is a server based technology, where the server can perform some function and the client’s browser can just see the output. For example, an ASP page can ask you for some contact information in a form, once you press the Submit button, the ASP code on the server will gather your responses and send out an email, and then generate a message that gets sent to the user saying “Thank you for your submission”. The client entered the data and saw the thank you message, and the server did the work of gathering the data and sending the email.
In 2001, Microsoft released the first version of ASP.NET. Web pages that end with “.aspx” are pages using this newer technology, whereas pages ending with “.asp” still use the older technology, commonly referred to as “Classic ASP”.
One of the biggest problems with Classic ASP was that it was so darned easy to use, anyone with some basic knowledge could create ASP pages. Once ASP started to catch on, anyone and everyone suddenly became a “web developer” and was creating website code which was (and in many cases, still is) being used in production environments all around the globe. As a true developer, this was extremely frustrating, because my profession was being flooded with amateurs and websites were being created left and right using all kinds of poor coding practices.
The other big problem with ASP was that for any task, there are an average of 10 ways to accomplish it. There are very few standards with Classic ASP. Whichever way the web developer felt like solving a problem, that’s how it was done without regard to programming standards, memory utilization, bandwidth, cpu cycles, scalability, etc. And with many ASP developers not being real “web developers”, the code that was being generated and put into production was many times poorly designed and completely inefficient. Out of the 10 ways to write a block of code, it was rare that the “best” option was chosen.
So along comes ASP.NET, a new technology which is very impressive, and very different from Classic ASP. Perhaps the biggest difference between the two is that Classic ASP is an interpreted language, whereas ASP.NET is a compiled language. With Classic ASP, all you needed was FTP access to the web server, and you have all of the code for all of the features of the website. With ASP.NET, if all you have is FTP access, then it is possible you only have access to the front end graphics and web page html code, but none of the actual source code being used to provide the back end features of the site. ASP.NET effectively split the source code which runs on the server from the client code which is sent to the users browser.
The other major advancement with ASP.NET is that it is harder to develop in. Many of those Classic ASP “web developers” were unable to make the transition to the more structured ASP.NET platform. ASP.NET is more of a true programming platform, it is fully object oriented, supports inheritance and delegation and remoting and all of those advanced programming features foreign to Classic ASP developers.
Lastly, perhaps the most important concept regarding ASP.NET is simply that it is a current generation platform for websites. Classic ASP is part of the previous generation of web technologies and has dwindling support from Microsoft and is riddled with security flaws. There are many thousands of developers out there still coding web pages in Classic ASP and selling them to clients who don’t know any better. ASP.NET came out in 2001, which means that it is now 6 years old and for an internet technology, that’s a lifetime. If your programmer is still developing your site in Classic ASP, it’s time to ask him why. ASP.NET is quicker to program in, has much more company and community support, and has a virtually endless amount of 3rd party companies writing software to integrate and improve the features and capabilities of it.
If your website is still using Classic ASP, it is now time to upgrade. If your developer is still suggesting Classic ASP over ASP.NET, it is time to get a new developer.
In speaking with people every day, it seems this is a pretty common point of confusion. Most people who aren’t developers figure that since “ASP” is so close to “ASPX” that the differences between the two technologies can’t be all that extensive. After all, ASP is technically 75% of ASPX, so upgrading to ASPX will only give 25% more in features or capabilities. When I tell them that the differences between the two technologies are pretty vast, they are often quite surprised.
From a user’s perspective, it is hard to make the differences obvious. After all, a web page that ends with an .asp extension can look pretty similar to a web page that might end with an .aspx extension. The two pages might even have the same functionality and operate in much the same way. So then what is the difference, and why does anyone care?
Back in 1996 (or thereabouts) when Microsoft came out with Active Server Pages (ASP), the web was still in its infancy. ASP was a new technology which solved a lot of the limitations of HTML and CGI, and was very easy to use. Because of this, ASP caught on and became hugely popular. ASP is a server based technology, where the server can perform some function and the client’s browser can just see the output. For example, an ASP page can ask you for some contact information in a form, once you press the Submit button, the ASP code on the server will gather your responses and send out an email, and then generate a message that gets sent to the user saying “Thank you for your submission”. The client entered the data and saw the thank you message, and the server did the work of gathering the data and sending the email.
In 2001, Microsoft released the first version of ASP.NET. Web pages that end with “.aspx” are pages using this newer technology, whereas pages ending with “.asp” still use the older technology, commonly referred to as “Classic ASP”.
One of the biggest problems with Classic ASP was that it was so darned easy to use, anyone with some basic knowledge could create ASP pages. Once ASP started to catch on, anyone and everyone suddenly became a “web developer” and was creating website code which was (and in many cases, still is) being used in production environments all around the globe. As a true developer, this was extremely frustrating, because my profession was being flooded with amateurs and websites were being created left and right using all kinds of poor coding practices.
The other big problem with ASP was that for any task, there are an average of 10 ways to accomplish it. There are very few standards with Classic ASP. Whichever way the web developer felt like solving a problem, that’s how it was done without regard to programming standards, memory utilization, bandwidth, cpu cycles, scalability, etc. And with many ASP developers not being real “web developers”, the code that was being generated and put into production was many times poorly designed and completely inefficient. Out of the 10 ways to write a block of code, it was rare that the “best” option was chosen.
So along comes ASP.NET, a new technology which is very impressive, and very different from Classic ASP. Perhaps the biggest difference between the two is that Classic ASP is an interpreted language, whereas ASP.NET is a compiled language. With Classic ASP, all you needed was FTP access to the web server, and you have all of the code for all of the features of the website. With ASP.NET, if all you have is FTP access, then it is possible you only have access to the front end graphics and web page html code, but none of the actual source code being used to provide the back end features of the site. ASP.NET effectively split the source code which runs on the server from the client code which is sent to the users browser.
The other major advancement with ASP.NET is that it is harder to develop in. Many of those Classic ASP “web developers” were unable to make the transition to the more structured ASP.NET platform. ASP.NET is more of a true programming platform, it is fully object oriented, supports inheritance and delegation and remoting and all of those advanced programming features foreign to Classic ASP developers.
Lastly, perhaps the most important concept regarding ASP.NET is simply that it is a current generation platform for websites. Classic ASP is part of the previous generation of web technologies and has dwindling support from Microsoft and is riddled with security flaws. There are many thousands of developers out there still coding web pages in Classic ASP and selling them to clients who don’t know any better. ASP.NET came out in 2001, which means that it is now 6 years old and for an internet technology, that’s a lifetime. If your programmer is still developing your site in Classic ASP, it’s time to ask him why. ASP.NET is quicker to program in, has much more company and community support, and has a virtually endless amount of 3rd party companies writing software to integrate and improve the features and capabilities of it.
If your website is still using Classic ASP, it is now time to upgrade. If your developer is still suggesting Classic ASP over ASP.NET, it is time to get a new developer.
Subscribe to:
Posts (Atom)