YaMessaging - A simple e-mail like messaging application

• Download source code - 543.6 KB
 

Introduction

This article contains a small email application which is developed using ASP.NET, C#, and ADO.NET.

Background

Last week someone asked a question in "The Code Project - Quick Answers" section on how to develop an email application. When I asked him about what he needed, he said he needed an email application that will only work inside an organization and there is no need to send/receive emails to other email providers. It was more of a messaging system where users can use their credentials to log into the site and can send/receive messages from other users of the site.

This made me realize that one of my previous employers also wanted such an application just for internal communication within the organization. Since we didn't have anyone to write one, we ended up using GMail for this.

The idea behind this small project that I made in couple of hours is to provide a skeleton for such an application. There might be some small businesses wanting such an application and they will perhaps be able to use this application with some changes.

This application is a very simple application sending messages to other registered users of the site. The database design is very simple and not optimized. There is no design on presentation layer (I am pretty bad at that). And to some people, the functionality might also seems simple like in a student project. The good thing about this application is that it follows proper n-tier architecture. Also it uses ADO.NET and I agree an ORM could have been used to do this but I like the power and control that ADO.NET provides and so I used it instead.

Using the Code

Let's start by talking about the architecture of this application. This application is designed using an n-tier architecture. I have a Data Layer that provides database related functionalities. On top of the data layer, I have my Data Access Layer (DAL) which has all the data access functionalities (using ADO.NET). On top of DAL, I have a Business Logic Layer (BLL) which contains the application specific functionality. And finally on top of the BLL, my presentation layer is developed using ASP.NET web forms. All these layers are in separate solutions so that changing a layer will have minimal or no impact on other layers. To visualize my application architecture:

The Data Layer

The Data Layer mainly contains the database schema and the Stored Procedures to use the database. I tried to put most of the database interactions as Stored Procedures. I always prefer having Stored Procedures. If I can't achieve something using Stored Procedures, I use parameterized commands. I never ever user string concatenated SQL statements from code as this approach is error prone and makes the application vulnerable to SQL Injection attacks. Let's now look at the database tables in the application.

The Stored Procedures created in the application are:

The Data Access Layer

The data access layer talks to the database, retrieves the results, and passes it to the business logic layer in the form of DataSets and/or DataTables. The DAL contains the following classes:

The Business Logic Layer

The BLL takes care of manipulating data as per the request from the user interface, and has some checks and operations that need to be performed. The main classes in our BLL are:

The Presentation Layer

The presentation layer is a set of ASP.NET web pages that provides the pages for "inbox view", "sent view", etc., to the user. The application currently has an administrator who can add new users and the added users can send messages to any other user. The users can also change their passwords. I have only put bare minimum validations in the presentation layer. I am using some client side and some server side checks to perform validations. The user management is being done by the application, i.e., ASP.NET Roles and Membership is not being used (this is because someone might want to use this application and his server might not support these features properly).

Following are screenshots of a few functionalities of the application.

How to Run the App

A few user IDs that I created for testing can be used to play around with the application.

• userid: one, password: one
• userid: two, password: two
• userid: three, password: one
• userid: Rajat, password: 12345

Also the Admin login for the application is:

• userid: admin, password: 12345

Points of Interest

This application has been developed in around 3 hours time so it might contain some bugs. The idea behind this application was as yet another attempt in explaining the n-tier architecture. I am really looking forward for some feedback and would really appreciate suggestions and constructive criticisms.

Planned Future Work

• Having the admin/users provide their SMTP server details and credentials so that their messages can be pushed to their email IDs.
• Have a nice frontend interface instead of this boring white, perhaps will try to incorporate jQuery UI for this.

History

• 20 April 2012: [Bug Fix]Validation error while adding recipients.
• 22 March 2012: First version.