Web programming - Project Report Project Group number : 6

Oct 24, 2014 - same part the report will finish with a discussion of method/results and our ... curse book related chapters, or browsing the stackoverflow's Q&A ...
448KB taille 4 téléchargements 270 vues
Web programming - Project Report Project Group number : 6 Members :

Daniel Csepregi Maxime Fabre Grégoire Moutotte

Supervisor/examinator: Anders Carstensen / Gustaf Mäkinen Nordquist Date: 2014-10-24 Contents 1 Introduction. 2 Analysis and theoretical background. 3 Implementation. 4 Results. 5 Discussion. 6 References. 7 Appendices.

1.Introduction 1.1. Background

Since the 43 years of existence of the Internet, programmers have tried to blow the barriers between traditional applications of Web applications. The progress of recent years in technology, download speed as well as development tools (including the Microsoft platform .Net) addresses these some shortcomings. Gradually, Web applications are becoming more feature-complete, while being easier to use. The aim of this project is to assimilate and understand how to create a web application using ASP.NET technologies. The group focused his work on creating functionalities asked in the different assignments. The group have just integrate a simple design of the web pages. It was important for the group to create a code clear and easy to re-used. That why, the group was focused on the architecture of the project and to put security and errors handling for a full ergonomic experience. 1.2. Purpose and questions of issue

The group wanted to find answers to different questions concerning the assignments    

How to create a clear and safe web application with Microsoft technologies? Understand and implement a good reusability architecture How API works concretely? How implement it in a web application? Which are the different good web technologies?

1.3. Presentation of the team The group is composed by three different persons. All these members haven’t the same nationality. Indeed two are French and one is Hungarian. The group have to cross the language borders. Each member of the group had already learned different programming languages, especially C#. However everyone aren't studying science computer. For the group it was the first time that they used Microsoft technologies to create a web application. Some member has programmed in PHP, but really understand the notion of API and create it was unknown for the group.

1.4. Outline The next part will introduce the reader more thoroughly to the theoretical background of the project. Chapter three will explain exactly the method used to create and to accomplish the project. Then, the fourth part will show the different results of the group’s creation. Finally, in the same part the report will finish with a discussion of method/results and our conclusion about the project.

2. Analysis and theoretical background First of all, we had taken a look at all the assignments before we have started doing anything related to coding. This helped us a lot, because we had a much clearer understanding what is the project about after analyzing and organizing the tasks.

2.1. Understanding the project

Since all of us have smaller or bigger experiences in the different programming language we have decided in the early beginning, that we will create for each data table a C# object, in order to benefit from the object-oriented language. As we got deeper with the code, we realized that it was worth to create objects, because it helps to create even more reusable code. In this project we have to create several tables, showing data to the user. Here, we also have taken advantage of code reuse. In the Admin section the user is always meet with the same UI. Furthermore, sometimes the GUI and the belonging object created according to the database logic is not equal. On some busy screen we want to show complicated information, which are based on several tables’ data, which requires a lot of data access to the Database. In these cases we have decided to involve objects within an object. To create a great solution we had to understand that we were creating a website for both library employees and library users. We had to take into consideration these factors.

2.2. Theoretical background Our team web development skills are based on this course. Since we were not that familiar with the ASP.NET at the beginning we made up our mind to start the project early. One of our group mate had a little experiences in Windows application C# programming, so for him WebPages were comfortable to use as well. However, after the MVC lectures we were worried about what to choose, but we continued with WebPages, because we do not want to take the risk with the new MVC technology. Although, after we finished our project, we are at the same opinion: With MVC could have been much easier. Another important source was obviously the internet. We have spent couple of hours reading the curse book related chapters, or browsing the stackoverflow’s Q&A section and a French programming website.

2.3. Architecture We have been suggested to create 3-tier web application. This consist of three different tiers. On the top lies the presentation (GUI)/Web Services (API) layer. This is responsible for the interaction between users (humans-GUI or other services-API) and the web server. The second layer is just under the first one called logical tier. At this point we create the business logic, which is required to serve the requests coming from the presentation tier. This layer provides services for the upper tier and uses the lower tier to collect, store and handle data from there. This is called the data tier. In our webpage the physical separation of the layers mentioned above look like this:  Presentational tier: “LibrarySystem” and the “API” projects  Logical tier: “BL”, “DAL” and “DTO” projects  Data tier: MSSQL Server  BL,DAL and DTO needs some words to explain it more detailed.

3.Implementation 3.1. Theoretical studies The theoretical studies have concerned the PowerPoint and literatures used during the course Web programming but the group has also read articles on internet and had literature studies in Jönköping’s student library. The laboratory has permitted to really assimilate the theoretical notions. 3.2. Method First of all, every member of the group thought together about the structure of the project. When the architecture was implement, the team separated the work between the different members. The first assignment of the project was evenly distributed. Each persons in the group worked alone on his parts of works. During the laboratory and some others day, the group planned a group meeting to see the project progress and if someone has difficulty to finish his parts. When one assignments was totally finish, a group meeting was planned to merge all the member’s parts on the final project. This meeting included merge, and different test phase. In general we have sought to create reusable code. An example can be found here 1.reference. We wanted to generate our “Add”-pages dynamically based on the objects. This means that from an existing object, we just loop through the fields, and automatically generate an appropriate input-field to it. We are using this in the “AdminBookAdd.aspx” and the “AuthorAdminAdd.aspx” page. As mentioned above, we sometimes have an object with a vast variety of properties. In AdminBookAdd case, we had to hard code some additional information, which property to be shown which not. Even though we are sure, that this is a time-saving and an excellent example of the reusability approach. Appendix1 is a great example of how we created nested classes in order to serve complex business needs.

3.3. Technologies used For this project the group used ASP.NET with the pattern web form and JavaScript language. We are using JavaScript to stick the menu bar always at the top of the page. CSS technology is responsible for the user-friendly appearance through the site. 3.4. Problems encountered The group decided to focus particularly to create the web application and avoid to loose time in configure Git for the group. There are some advantages to do this, but of courses, a lot of drawbacks. In this project the group was composed of three person. It’s possible to work without managers versions as Git, but it requires organization. The group don’t had problem to merge the different parts of the members, but they had to plan a several group meeting and take time only to execute this task.

4.Results 4.1. Basics We have 9 pages related to the administration section. Book, Borrower, and Author are the main sections. Each have an “Add”, a “Detailed” and a normal, browse site. Here you can find a really deep and high percent of code reuse. These sites are ease to maintain and change, if it needed. To fulfill the requirements for the public session, we have created a SearchPage, and a Browse page. These two pages are using the same Business logic, and there is a slight overlay regarding the methods used in the admin section. We have an Error page as well, where we can show some basic error messages. Our Masterpage is called BasicMasterpage. As it suggests, we can make sub-masterpages of it, and connect them to the different part of the site. For example appendix3 for users, and for admins. No advertisements on the top. We implemented the LogOn-LogIn part into the Basic Masterpage, so it is always easy to interact. Our security system is built in every page. Some pages are not open to the public. We are using encryption for password and we are try to avoid SQL injection as well. Authentication is not enough, some pages require specific authorization. We are storing the user information in the Session variable, we can reach them anywhere, anytime. Appendix 5 We have inserted a stand-alone API project containing the widget.html. This is an example of usage of our API.

4.2. Architecture With a good division of labor, we were able to successfully complete all the features requested. To, among other things to improve our teamwork, we decided to follow the famous model consists of: Short Name

Long Name

Description

BL

Business Layer

All the business related logic, validation and rules.

DTO

Data Transfer Object

It transfers the data throughout the application (from DAL to BL to PL)

DAL

Data Access Layer

All the functionalities related to connecting database, fetching records, executing scripts, etc..

UI

User Interface

All the interactions between the user and the app

And out of this method is a fifth part for the interaction with outside widget:

API

application programming interface

gate data exchange method REST

This model allows to separate the various parts of the project in order to see more clearly and to be closer to the projects in the professional world. This makes it easy with this model of organizing to the division of tasks and improve parts because everything is divided in blocks of

functionality, like a car. The various parts work independently and interact. For example if you want to change the database, only the "DAL" part will change.

BL This section contains all the business logic of the project. It acts as an interface between the DAL office (to check the information in the database) and the controller form of web pages. Thus in this part there are many functions to retrieve data from the DAL, to get in shape, sort, validate to transmit to the controller exactly what it wants.

DTO This part is located all the classes that contain information about objects such as books (author, name, date, title) but also contains information related to the parameters of a borrowed book (borrowing date, date of restitution ..) this information could be contained in another model and inherit the class "book" because all books borrowed: are books but all books are not books borrowed. But as a single class in our case would have inherited the class "book", we decided to put everything together. There are also containers as author, borrower ... It's model may also contain methods directly related to the processing of data such as conversion methods, GET, SET. Through this section, it is possible to have a quick overview of the entire project and to understand what information will be handled. This makes it easy to add or delete items.

DAL This part is located all the classes to interface to the database. This allows for each part (book search, user login ..) to execute a SQL query and retrieve the result for inclusion in DTO container request. Each method consists of a string to formulate the SQL query (with table joins, for example to retrieve the name, barcode, ISBN of free according to its borrower). To execute this query, it is first necessary to open a connection thanks to the "SqlConnection" function, then the query through the "SqlCommand" class and the method is executed "ExecuteReader()" and finally reads data collected through the "SqlDataReader" class and "Read()" method. Once the data is read, it stores it in a DTO container and returns the result to BL for data preprocessing.

UI This is the human - machine interface. It is through this part that the user can interact with the server, view the answers, and manipulate the data on the client interface. We decided to use the Web Form architecture for this project for two main reasons:  We already knew the MVC architecture, which is now probably more used than Web Form with its side easier to use and cleaner. Thus, we preferred to explore a new architecture for encoding as Web Form.  We had already started the project in Web Form before during the MVC. We started to get familiar with. Each file represents a different web page of the project. In order to not repeat on each page as the recurring logo or menu information, we decided to use the "basicMater" page to encapsulate all other pages based on the URL through ASP function "ContentPlaceHolder. "Each page consists of a view including HTML, CSS, JavaScript, ASP instructions but also to liaise with the controller as the label, repeater, the input. The processing of data by controllers running on the server through the sending client / server Ajax data. This avoids having to handle every refresh the page.

API Finally, in this last part, we had to create a server side interface to the external widget (from other server) able to connect to our application in REST (GET) in order to transfer data in JSON format. Unfortunately, the exchange of cross domain JSON data is not allowed, so we had to use the format JSON-P. So the widget sends a request to our server in GET and our server returns the response as a file (external resource) our JSON file containing JavaScript. This is a hack: and not normal use.

4.3. Developing and improving opportunities Our “Book” class contains a numerous different subclasses. When such complex page as the Book administration came across, we had some performance issues. In order to have only one line for each book, we have to gather all the authors for the specific book. In this particular situation it takes too much Database calls. (Approximately ‘n’ calls where n= number of books). In order to reduce these unnecessary data traffic we had developed a cache system. This is able to reduce the number of database calls, but requires run-time memory. Appendix4 is the code example. Since we are not using MVC, our mapping and paging system could be more efficient and logical. Even though we tried to make our pages simply. Earlier mentioned our focus was to create reusable code. In order to improve that we can imagine to create in the future a Tabel in the database, where we can add informations about the objects, what type of input field they need, to be shown or not. With the help of this table we could be able to build “Add”-type pages easily.

We can see a huge possibility in improving our SQL queries. Instead of hard coding the SQL-s into the C# we could create Stored Procedures at the Data tier. This would results a greater transparency over the SQL-queries. Unfortunately we have ran out of time, but it would have been a huge achievement if we could have create our own server control for example for the data-tables. We would only have to adjust some property and we would have a reusable own-customized representation of data.

5.Discussion 5.1. Discussion of the project’s Architecture It was very interesting to learn a new way to organize the code, allocate all the functionality by Category. Thus each of us was able to work independent of parts they wanted and in the end you have assembled all the code into one. We have the right to adapt the DTO that the model is valid for all the codes Nevertheless, our project being quite short, we could dispense with the BL part diretement and link the controller UI to DAL and it would not be the case for larger projects.

5.2. Discussion of technologies used The group had not a lot of freedom of choice concerning technologies to use. Indeed the team had to create the web application with ASP.NET. However we had chosen to program with the pattern web form. ASP.NET MVC is for the group better to work with, but all the member of the group begin the assignments one with web form pattern. For do not change all the structure of the project, the group decided to continue with this pattern. In the client side, the subject forced to use basic JavaScript language. The group forgot the idea to use JQuery for example. Concerning the design of the web application, the group only use basic CSS. A good idea will be to use Less for more comfort.

5.3. Discussion of the working group’s method The method chosen by the group was pretty efficient. Each group meeting was a good way for everyone can know the project progress and discuss about the different functionality and how to improve them. The bad point of the group method was to not use a managers versions like Git or SubVersion. However the group didn’t lose a lot of time to not use it, indeed firstly, only three persons worked on the project, secondly the web application to create was pretty small. Work without Git was possible. It just need that the group be rigorous and a implement good organization.

5.4. Conclusion What we really like in our result is that even though we were working more separately, when we repeatedly merged our result into one version, it was not hard at all. It is because at the beginning we discussed the path that we want to go. We have always stayed in touch with each other, thus we could feel, that the control in our hand. We are all sharing the same positive opinion about creating reusable code. If we could restart the project, we would put more emphasis at the beginning to create general controls, methods, which could be useful for the whole life of the project. Right now our code might be not unified. We tried to simplify the methods that we have written before. But we could have spare a lot of time if we have created them together at the very beginning. We learned a lot about how can to different nations work together, using a third-party language. It was really fun to spend evenings, afternoons, sometimes the whole night to make that function at least once work. Though occasionally it was stressful, but eventually that is why we have come here to Jönköping.

6.References 1,http://stackoverflow.com/questions/531384/how-to-loop-through-all-the-properties-of-aclass visited:2014.10.20. 2, Web programming lesson 3, http://fr.openclassrooms.com/ (french tutorial)

7.Appendices appendix1

appendix2

Appendix 3 Without and with advertisement

Appendix 4 - cache system

…. …. ….

Appendix 5