ASP.NET Development

Software Development Technologies

Bobylog team has in-house expertise in ASP.NET development to the highest professional standard. We develop software applications based on the following tools and methodologies.

Bobylog - ASP.NET Development

Microsoft .NET Framework:

  • Web Server: ASP.NET MVC, Web Forms, Web Api, Soap, Xml;
  • Web Client: HTML5, CSS3, Ajax, JQuery, JQuery Mobile, Json, RequireJS, Event.js, Node.js, Knockout.js, Modernizr, Angular.js, LESS, YUI, CSS Grid (960, 1140);
  • Windows Desktop: Windows Presentation Foundation (WPF), Windows.Forms;
  • Databases: Microsot SQL Server, MySQL, Oracle, PostgreSQL;
  • Languages: C#,, RegEx, C++, JavaScript, XPath, T-SQL, PL/SQL;
  • 3rd party: GUI: Telerik, Infragistics; ORM: LLBLGen;
  • UnitTests: NUnit; Behavior Driven Testing (BDT)


What is ASP.NET MVC?

ASP.NET MVC, that is supporting ASP.NET development, is a web development framework from Microsoft that combines the effectiveness and tidiness of model-view-controller (MVC) architecture, the most up-to-date ideas and techniques from agile development, and the best parts of the existing ASP.NET development platform. It’s a complete alternative to traditional ASP.NET Web Forms, delivering considerable advantages for all but the most trivial of web development projects.

MVC Architecture

ASP.NET development has been a great commercial success, but, the rest of the Web development world has moved on, and even though Microsoft has kept dusting the cobwebs off Web Forms, its essential design has started to look quite antiquated.
In October 2007, at the very first ALT.NET conference in Austin, Texas, Microsoft vice president Scott Guthrie announced and demonstrated a brand new MVC Web development platform, built on the core ASP.NET development platform, clearly designed as a direct response to the evolution of technologies such as Rails and as a reaction to the criticisms of Web Forms.

First Reason to choose MVC for ASP.NET development

User interaction with an MVC application follows a natural cycle: the user takes an action, and in response the application changes its data model and delivers an updated view to the user. And then the cycle repeats. This is a very convenient fit for Web applications delivered as a series of HTTP requests and responses.

Second Reason to choose MVC for ASP.NET development

Web applications necessitate combining several technologies (databases, HTML, and executable code, for example), usually split into a set of tiers or layers. The patterns that arise from these combinations map naturally onto the concepts in MVC.

The ASP.NET MVC Framework implements the MVC pattern into the ASP.NET development and, in doing so, provides greatly improved separation of concerns. In fact, ASP.NET MVC implements a modern variant of the MVC pattern that is especially suitable for Web applications.

By embracing and adapting the MVC pattern, the ASP.NET MVC Framework from ASP.NET development provides strong competition to Ruby on Rails and similar platforms, and brings the MVC pattern into the mainstream of the .NET world. By capitalizing on the experience and best practices discovered by developers using other platforms, ASP.NET MVC has, in many ways, pushed forward beyond what even Rails can offer.

Powerful Routing System

The style of URLs has evolved as Web application technology has improved. URLs like this one:


are increasingly rare, replaced with a simpler, cleaner format like this:


There are some good reasons for caring about the structure of URLs. First, search engines give considerable weight to keywords found in a URL. A search for “rent in Chicago” is much more likely to turn up the simpler URL. Second, many Web users are now savvy enough to understand a URL, and appreciate the option of navigating by typing it into their browser’s address bar. Third, when someone understands the structure of a URL, they are more likely to link to it, share it with a friend, or even read it aloud over the phone. Fourth, it doesn’t expose the technical details, folder, and file name structure of your application to the whole public Internet, so you are free to change the underlying implementation without breaking all your incoming links.
Clean URLs were hard to implement in earlier frameworks, but ASP.NET MVC from ASP.NET development uses the System.Web.Routing facility to provide clean URLs by default. This gives you control over your URL schema and its relationship to your application, offering you the freedom to create a pattern of URLs that is meaningful and useful to your users, without the need to conform to a predefined pattern. And, of course, this means you can easily define a modern REST-style URL schema if you wish.

Mobile Web Development in ASP.NET development

There are a number of good reasons to choose the mobile Web as a development platform.

First, with mobile web development, you only need one development tool set as I mentioned before. You do not need to learn Java, Objective-C, and C# to build for each major phone.

Second, this also means that you can target multiple types of devices with one codebase. This a major boost for both productivity and maintenance. Because of browser incompatibilities, it is not “write once, run anywhere.”
That would be fantastic. But a lot (or perhaps even most) of the code can be shared across browsers in modern smartphones.

Third, if you already have experience in web development generally, you are already on your way to working on the mobile web. Everything you learned in doing web development applies to mobile. All you need to do to be effective in mobile development is to pick up some additional skills.

Fourth, you can deploy anytime. This is actually a very big deal. Find a critical bug in a mobile website? Push a quick fix out to the server farm. Find a critical bug in a native application? Go through the relevant app store and their (sometimes) finicky process to get your change pushed out.

Fifth, no one can keep you off of their platform. For many, this may not even come up as a concern but it can be a very big deal. Anyone’s application can be removed from any app store (though Apple is most notorious for this) and there is nothing you can do about it. Having a mobile website along with native applications gives you a backup strategy if a store decides to remove your application. By targeting the mobile web, you are not held captive by those who run the app stores. The only one holding you back is you.

Challenges For Mobile ASP.NET development

So what is not to like about mobile web development? In reality, there are several advantages to doing native mobile application development. Here are a few things to keep in mind.

First, if you ever found yourself complaining about desktop browser fragmentation, you haven’t seen anything yet. On the desktop, you primarily have Internet Explorer, Chrome, and Firefox and their various versions. Since the latter two automatically update, you really only have to deal with one version of both Chrome and Firefox and a few of Internet Explorer. The mobile browser landscape is far more fragmented. Users of iOS tend to upgrade quickly, which pushes the newer, more interesting browser versions of mobile Safari more quickly. Android users are the exact opposite. They rarely upgrade and old browsers stay around for much longer. Additionally, manufacturers tweak their Android implementations and their default browsers, so you will get (seemily endless) inconsistencies at times. Along with that you also have two versions of the Windows Phone 7.x browser out as well as mobile Firefox and Opera. At the moment you may not want to forget Blackberry as it is still hanging on to some market share, which gives you another few variants of a webkit-based browser like you have on iOS and Android (though traffic from Blackberry devices is on a serious decline). And we have the recent addition of Firefox OS, though the numbers remain small for now. And that is just the browser landscape for smartphones. Fragmentation only gets worse if you start supporting older devices.

Second, native applications get more capabilities than mobile web counterparts. Native applications can register a phone for push notifications, even while the app is not running. You cannot do this with mobile websites. You can’t currently upload a photo directly from a phone to a site through the browser except in iOS 6+ and Android 4+. Native applications with their native rendering also benefit from improved performance. But the good news is that as time goes on the browsers improve and get more functionality than they had before. They also become faster. But it is likely that mobile web applications will continue to trail native applications in terms of capabilities.

Ajax with jQuery for ASP.NET development

Ajax, which stands for Asynchronous JavaScript and XML, lets us fetch and send data to and from a server asynchronously, in the background, without interfering with the user’s experience. As a user, you’re unaware of what’s happening until the data has been fetched and then shown on the page. Although Ajax stands for “Asynchronous JavaScript and XML,” the most common format for getting data back is now JSON, or JavaScript Object Notation. It is used in real-world third-party API to pull in data and display it on a page. To do this, you’ll need to use JSONP, a method of requesting data from third-party web sites. Ajax has been somewhat of a buzzword in recent years, but it’s simply a way of asynchronously fetching data.

The “x” in Ajax may stand for XML, but the format nearly everyone prefers these days is JSON, which stands for JavaScript Object Notation. Because JSON is newer than JavaScript, not all browsers come with native JS methods for parsing it. If you’re not worried about older browsers that don’t support JSON you don’t need to do anything. Thankfully, there are scripts out there to provide JSON methods to older browsers.

jQuery comes with jQuery.ajax(), a complex and powerful method to handle Ajax requests ( This method is different from others because you don’t call it on a jQuery object containing elements, but on the jQuery object itself.


With the release of the .NET Framework, Microsoft introduced a new data access model, called ADO.NET. The ActiveX Data Object acronym was no longer relevant, as ADO.NET was not ActiveX, but Microsoft kept the acronym due to the huge success of ADO. In reality, it’s an entirely new data access model written in the .NET Framework.

ADO.NET supports communication to data sources through both ODBC and OLE-DB, but it also offers another option of using database-specific data providers. These data providers offer greater performance by being able to take advantage of data-source-specific optimizations. By using custom code for the data source instead of the generic ODBC and OLE-DB code, some of the overhead is also avoided. The original release of ADO.NET included a SQL provider and an OLE-DB provider, with the ODBC and Oracle providers being introduced later. Many vendors have also written providers for their databases since.

Database Schema for ASP.NET development


The best way to describe normalizing a database is think of it as breaking your data down to its logical units, i.e., the smallest possible objects that make up your data. Then, for each one of them, you need to make sure that it lives in it’s own table, that the data is not replicated, and that the table in some way relates to other tables where appropriate.

Why Normalize Data?

Normalization isn’t just a fad—it’s probably the most important part of database design. Without it, you can get into a real mess—if not right now, when you need to make changes to your schema by adding more functionality or by fixing design flaws.

Data should be normalized to remove repeated or redundant data. Doing this instantly reduces the amount of space your databases need to occupy, as well as speeds up scans of your tables—with the free bonuses of gaining increased maintainability and scalability.

By reducing the amount of repeated data, the chance of finding errors in your data is dramatically
decreased simply because there is less data to contain errors.

Types of Normalization

There are many different degrees of normalization in both academic and real-world settings. In most cases, the different levels of normalization are linear—for example, there are the nth Normal Forms, whereby First Normal Form is the simplest, and the Third Normal Form is more complicated.

There are four main forms of normalization. Each one represents a different level of normalization—from not normalized at all to the nirvana of normalization.

First Normal Form

With the first form, the goal is to remove any repeated groups of data from any tables. That’s an easy concept to grasp: If you’ve got the same few text labels appearing in a table, then they need to be normalized into their own table, and a foreign key should be added to the table that is storing your data. In addition, if you have multiple columns in a table storing the same type of information, this should also be hived off to a separate table. Remove repeated groups of data.

Second Normal Form

Using the second form, all rows containing the same information should have that information hived out to separate tables with foreign keys linking the data.

Third Normal Form

When trying to achieve the third normal form, all columns in the table that are not directly dependent on the primary key should be removed and placed in their own tables, with foreign keys creating relationships between the tables.

Domain\key Normal Form

This form is the nirvana of normalization. As mentioned previously, databases cannot be more normalized than they are when they’re in the Domain\key normal form. Each row of every table has its own identifying column.

Designing a Normalized Database

To create a normalized database, you first need to understand the applications that will be using your database and how they need to work, their feature sets, and any further modifications or features that are to be implemented with future releases. Once you understand the applications, you can begin to map out the database structure.

First, write down a list of all the “things” in your applications, be they customers, pets, products or countries—each of these items will need their own table. Second, work out the different ways in which you need to pull all the data together to provide the kind of information you will need. For example, if you want to know which of your customers in England have a pet badger and bought your kitten warmers, you must have a Purchases table. If you don’t, you’ll need to add one. Third, map out all of your tables on paper or using a database design tool, such as the diagram tool in SQL Server. Fourth, sit down with each of the application-specification documents again, going through each of the features you require and making sure your database can provide it. If you identify any feature that the database can’t fulfill, rethink your design so that it can. Once you’ve gone through the fourth step a few times, you should be ready to start creating your tables, so dive in, remember the rules, and follow your design.

To Delete or Not to Delete . . .

When a record is deleted, it’s clear that the data it represents is irretrievably lost without the use of restoring database backups. In many circumstances, it’s not a problem that the data has been removed, but as soon as you’re asked to report on data that is no longer there, you’ll be in a pickle.

Some laws require that certain types of data be stored indefinitely, and other laws require aspects of data to be deleted when it’s no longer relevant. Be sure to check with your appropriate departments if there is any risk of running afoul of the law.

There are several ways in which you can ensure that you never delete your records, thereby ensuring that they’re always available to be reported on and queried. Archiving the data into a different database is a simple way to ensure your current working sets of data are kept clean by only storing the most recent data. By maintaining another database with the same schema as your current set, you can easily transfer data across and maintain it for full reporting and queries.

Compiling your data into statistics where appropriate and just storing the compiled statistics instead of the raw data is another very easy way to ensure that all of your data is kept intact as you remove old information from the live tables.

Other ways in which you can preserve data is by versioning records, via version numbers, Boolean (bit) fields indicating the current row, or by using date spans that indicate a range of dates in which the data is valid. This method can be somewhat cumbersome because your tables never actually shrink in size; nothing is ever deleted, not to mention the fact that you have extra columns storing versioning information.