The solution you will develop throughout this book is for a fictitious company whose human resources department needs to... more

The solution you will develop throughout this book is for a fictitious company whose human resources department needs to approve, deny, and report on vacation or holiday time requests by their employees. The solution will be developed using Visual Studio 2008 and implemented as an ASP.NET 3.5 application written in C# with SQL Server 2005 as the back end.

The concept is simple, and the solution is designed to be flexible enough that you can extend it for your own business needs. This chapter defines the requirements for the project and introduces how the solution will be architected. Each chapter details specific requirements and implements a solution in a three-layer architecture: the user interface (UI), the business logic layer (BLL), and the data access layer (DAL).

... less

Before starting to develop the functionality of the application that is specific to Mary’s requirements, the focus will be... more

Before starting to develop the functionality of the application that is specific to Mary’s requirements, the focus will be on building the overall architecture for the three layers in the application. The architecture is independent of the requirements and provides all developers working on the project with a standard way of presenting data to the user, validating data, and saving data to the database. The first layer to be discussed is the data access layer (DAL). This layer manages communication between the database and the business logic layer.

One of my favorite new features in Visual Studio 2008 is LINQ to SQL. You can find plenty of material on the web covering this topic. www.asp.net has some great videos covering this topic, showing you how to quickly create classes that mimic your tables and then bind them to the GridView control to display them to the user. You can also enable insert, update, and delete in a GridView with little or no code. The demos are great, and LINQ to SQL truly helps with rapid application development. I have found that there aren’t as many articles about integrating LINQ to SQL into a three-layered architecture. The samples usually have the user interface directly communicate with the entity classes created by the ORM Designer. This chapter covers the following:

• Exploring options for creating a data layer

• Walking through the traditional approach

• Implementing a similar design pattern using LINQ to SQL

If this book has one chapter that is a “must read,” it is this one.

... less

The business logic layer (BLL) in the three-layered architecture is really the brains of your application. It is here that... more

The business logic layer (BLL) in the three-layered architecture is really the brains of your application. It is here that you model the business process defined by the user and enforce validation rules to protect the integrity of the data. The BLL sits between the user interface and the DAL. Technology is constantly changing and there are always new ways of presenting data to the user, such as with AJAX, Silverlight, or even your phone, but the business rules for your application remain the same regardless of the user interface. The design of the BLL should be flexible enough that any type of front end can use it, even a Windows service.

Depending on the size and budget of your application, the database could start out as Access but eventually migrate to SQL Server or Oracle. Again, the business rules do not change based on the database, so all the business rules should be separated from the data access code. If you were to put your business rules in stored procedures or Oracle packages, then you would be married to that database. Changing databases becomes quite a daunting task. If a database is used simply as a place to store the data, then changing databases is much easier.

To successfully develop an application that can easily work with multiple user interfaces or multiple databases, you should model your business process and place all your validation rules in the business logic layer. A BLL typically consists of classes that represent a single entity or lists of entities. Users can select, add, update, or delete data through these entity objects. Selecting data simply retrieves the records from the DAL and maps the fields to an appropriate property of the object. Adding, updating, and deleting data is where the validation rules come into play. Usually the validation rules for adding and updating are the same, such as required fields, boundary checks, and uniqueness. When deleting, you need to check referential integrity issues or other rules that would prevent a user from deleting a record.

Communicating the broken rules back to the UI is also the responsibility of the BLL. Some schools of thought put this logic in the UI with validation controls, but this marries you to a specific type of UI. If you switch the UI, you have to rewrite all that code in the new UI. By keeping the validation rules in the BLL, you gain code reuse and consistency between user interfaces.

This chapter focuses on creating the base classes for all objects in the BLL. Future chapters build upon this pattern when creating the functionality for requesting vacation, viewing data, and querying data. It is important to understand the concept of the base classes, especially the abstract methods that you must implement when inheriting from these classes.

... less

Have you ever built an application with a tremendous amount of functionality, one on which you’ve spent a great deal of time... more

Have you ever built an application with a tremendous amount of functionality, one on which you’ve spent a great deal of time meeting all of the user’s requirements, designing the perfect database, and creating a slick object model to handle the business rules, yet the user’s first comment after your demo is “the font is too small”? Users don’t care how great everything works behind the scenes and how much time and effort you expended considering multiple scenarios and confirming that the application’s functionality works as expected. All they have to say is that the font is too small. What a way to take the wind out of your sails. I’ve met a lot of developers in my time and most think very similarly. Developers are very logical and possess the skills to dissect a problem into manageable pieces. They can translate requirements into a data model or object model without blinking an eye, but when it comes to building the user interface, things start to fall apart. The tools used to develop slick interfaces aren’t the same tools used to design code or databases, and developers have to come out of their comfort zone to become a Picasso. Lining up text boxes on a screen isn’t typically the programmer’s primary focus. That’s what junior developers are supposed to do, right? It’s like being a percussionist in a band. You are responsible for keeping the beat, but the lead singer gets all the glory while you are buried behind the drums where no one can see you.

Of course, there is some merit in what the user is expressing. The look and feel of an application can make or break a system regardless of whether the application meets the user’s requirements. A simple and easy to use application that covers 75% of the requirements will win hands down every time over an application that is hard to use and covers 100% of the requirements. You are responsible for making the overall user experience pleasant and intuitive. Intuitive is the key, as most users don’t read documentation even if it exists. They just want to dive right in and start using the system. If they can’t figure it out, they are unlikely to continue to buy into the system.

... less

Have you ever taken over an application for another developer and been asked to track down a problem only to find that an... more

Have you ever taken over an application for another developer and been asked to track down a problem only to find that an exception was being thrown by the code but the previous developer was ignoring it? I’ve seen this happen plenty of times. VB used to make it easy to cover up exceptions with the dreaded On Error Resume Next statement. This would tell the application to just keep on executing line after line even if an exception occurred. I’ve actually heard the excuse “Well, if the system doesn’t show the user the exception, the application will look more professional.” Anyone with that type of mentality toward a system should be moved to technical support and they’ll change their mind immediately. These are some of the toughest “bugs” to track down.

An exception is an error that occurs during execution. Sometimes there are known exceptions that the developer can handle, while other exceptions are unexpected. An example of a known exception would be when you try to write to a file and it is marked as read-only. You can trap this exception and give the user a friendly message to change the file’s attributes. Unexpected exceptions are obviously different because you can’t anticipate them, but you still need to make the user aware that something happened and the system didn’t perform as expected. You would hope that users call the help desk to let someone know that a problem has occurred so you can fix it, but usually they won’t. Even if they do, it is often hard to get a clear explanation of exactly what they were doing in order to give you a clue as to how to fix it.

Wikipedia defines exception handling as “a programming language construct or computer hardware mechanism designed to handle the occurrence of a condition that changes the normal flow of execution.” Essentially, this means you need to add code to your application that expects unexpected exceptions to occur. Your strategy for exception handling should be designed early in the development process, and one of the issues that should be addressed is not relying on the user to let you know what happened, but instead letting the system tell you what happened and when. Luckily, Microsoft has given you a few pre-built options when it comes to exception handling, and rather than reinvent the wheel you can just piggyback off of their exception handling strategy and incorporate it into your application.

... less

For some reason, security seems to be the last thing developers want to think about when developing a system. It’s much more... more

For some reason, security seems to be the last thing developers want to think about when developing a system. It’s much more fun to create new pages, create databases, and play with the latest technology than it is to write boring old code where there isn’t much bang for your buck. Wouldn’t it be great if security were something you didn’t have to think about and it were part of a framework that you could reuse and customize for your own applications? Well, you’re in luck. This chapter provides just that. After reading this chapter, you’ll have a framework in place that enables users to create roles and specify whether another user has read-only access, full access, partial access, or no access to a page.

... less

How many applications have you written that have some type of workflow for which one user enters a request and a second user... more

How many applications have you written that have some type of workflow for which one user enters a request and a second user approves it? Or one user enters some data and a second person verifies it? In the real world these business processes are ubiquitous. Human resources might have a vacation request process, a travel request process, and even a weekend stay-over process. Many companies have new hire processes whereby new users must be set up on the network, entered into the payroll system, have their e-mail set up, have a phone ordered, and more. Software development shops have change request processes that require all requests to be approved before being worked on. The list goes on and on. If you take a moment to consider all the business applications you’ve built, you’ll probably find that a good number of them include workflow.

In its most basic form, a workflow is any defined business process that entails an issue moving from one state to another; and it requires that the current owner of the issue transition the issue to an end point. A simple document approval workflow is represented in Figure 7-1.

... less

Another key piece of functionality that enterprise applications usually require is the capability to send notifications when... more

Another key piece of functionality that enterprise applications usually require is the capability to send notifications when specific events occur in the system. The notification is usually an e-mail message that is sent to a user. Some applications define notifications as alerts, which is essentially the same thing. The system is proactively communicating with users to let them know that certain events occurred or certain actions need to be followed up on. For applications that have workflow, notifications are key pieces of functionality that people tend to rely on to let them know they are supposed to do something. It is helpful if the e-mail message has a link back to the application and the specific screen that enables the user to take action. Once users get used to receiving these e-mails they become dependent on them, which is a great selling feature for your application. Mary didn’t consider this functionality in our first conversation, but from experience I knew she would eventually ask for it so I brought it up. Luckily, the framework being built in this book has this capability, so it is easy to add this functionality without extending the deadline of the project too much.

... less

For some reason reporting always seems to be an afterthought when it comes to developing an application. Everybody is concerned... more

For some reason reporting always seems to be an afterthought when it comes to developing an application. Everybody is concerned about the design of the data entry screens and what data should be collected, but far too often applications are built and quickly become a data graveyard. The data goes in but it never comes out. Problems always seem to arise near the end of the development cycle when users start thinking about reports, and then they realize that they aren’t collecting the right information or they don’t have enough information for a report to make sense. In these situations, you are forced to tell the user that either you can’t create the report or you have to make wholesale changes to the application in order to accomplish what they want. That’s not a position you ever want to be in.

Another issue with reporting is that many applications don’t even include reporting, and an entirely different tool and application is used for reports. There are plenty of tools that just handle reporting, such as Business Objects Web Intelligence, Crystal Reports, Hyperion, SQL Server Reporting Services—the list goes on and on. Producing reports takes an entirely different skill set than the typical programmer possesses.

... less

When dealing with data, some common features eventually make their way into most systems. Data often needs to be presented... more

When dealing with data, some common features eventually make their way into most systems. Data often needs to be presented in a table-like fashion on the screen, displayed in a report, or exported to a file in a standard format such as .csv or Excel. When displaying data in a table, users often have to page through data to find specific records. When displaying data in a report, users can use Find or Search functionality in the report viewer to find exactly what they are looking for. In many cases, users are directed to export the data from the system to Excel and then muck around with the rows and columns to filter the data they are looking for. I tend to think of HTML tables, reports, and exports as different interfaces wrapped on top of the exact same business objects that retrieve the data. All of these processes need to pull data from the database and display it to the user in different forms. The business layer doesn’t really care what format the data is in. It just needs to serve it back in a way that the user interface can understand, and users often need the capability to present the data in the same fashion, but filter it differently.

... less

One of the big buzzwords these days is “dashboard.” This is one of those words that seems to have made its way into the vernacular... more

One of the big buzzwords these days is “dashboard.” This is one of those words that seems to have made its way into the vernacular of executive management. “I want to see a high-level snapshot off all activity in all my divisions, by department, by business unit, by person.” A dashboard is a web page that contains critical information displayed as graphs, links, speedometers, reports, and many other forms. The goal of the dashboard is to give users a high-level view of the data collected in the application. The concept is similar to the dashboard in your car. You see the fuel gauge, your speed, the battery charge, the RPMs, and so on, in one place, which enables you to quickly make decisions based on the information provided.

Many vendors are more than willing to sell you their out-of-the-box solutions and tools to create these dashboards. They usually include a demo with pie charts, line graphs, or speedometers that are used to show you the health of your organization. These demos may throw in some other buzz phrases like key performance indicators, and they make it look very easy with the staged data in the demo database. Yes, these tools can be useful and make an application look professional.

... less

Building a solid audit trail is critical in many of today’s enterprise-level applications, not to mention it can get you... more

Building a solid audit trail is critical in many of today’s enterprise-level applications, not to mention it can get you out of a heap of trouble when people start asking questions about missing data. Wouldn’t it be great if you could produce a nice, fancy report that indicates whenever anyone adds, updates, or deletes a record? Not only is an audit trail good for covering your butt, but an increasing number of regulations mandate that system activity be traceable.

Audit trails are another one of those features that never seem to make it into the first round of requirements. “Oh, we’ll get to that later after we figure out what we want” is a common refrain. Well, it’s much easier to take care of auditing up front, rather than after the fact; and with the pattern that has been defined in this book already, it is easy to slip in an audit trail without refactoring the entire project.

... less

If you have made it this far in the book, then you probably realize that about 80 percent of the code in each chapter is... more

If you have made it this far in the book, then you probably realize that about 80 percent of the code in each chapter is repeated. The stored procedures all look the same and have the same five standard procedures for select all, select by id, insert, update, and delete. The Data classes all look exactly the same because they implement the same base class and implement the same abstract methods. The editable business classes inherit from either the BaseEO or BaseEOList object and implement the same standard methods. Most of the customization to each of the classes varies according to the fields in the table the classes are managing.

... less