Things to do and take care of before building an application.
For my reference:
|Authentication||Lack of authentication across trust boundaries|
|Storing passwords in a database as plain text|
|Designing custom authentication mechanism instead of using built-in capabilities|
|Authorization||Lack of authorization across trust boundaries|
|Incorrect role granularity|
|Using impersonation and delegation when not required|
|Caching||Caching volatile data|
|Not considering caching page output|
|Caching sensitive data|
|Failing to cache data in a ready-to-use format|
|Exception Management||Revealing sensitive information to the end user|
|Not logging sufficient details about the exception|
|Using exceptions to control application flow|
|Logging and Instrumentation||Failing to implement adequate instrumentation in all layers|
|Failing to log system-critical and business-critical events|
|Not supporting run-time configuration of logging and instrumentation|
|Logging sensitive information|
|Navigation||Mixing navigation logic with user interface components|
|Hard-coding relationships between views|
|Not verifying if the user is authorized to navigate to a view|
|Page Layout (UI)||Using table-based layout for complex layouts|
|Designing complex and overloaded pages|
|Page Rendering||Using post backs and page refreshes for many user interactions|
|Using excessive page sizes that reduce performance|
|Presentation Entity||Creating custom entity objects when not required|
|Adding business logic to presentation entities|
|Request Processing||Mixing processing and rendering logic|
|Choosing an inappropriate pattern|
|Service Interface||Breaking the service interface|
|Implementing business rules in a service interface|
|Failing to consider interoperability requirements|
|Session Management||Using an incorrect session store|
|Not considering serialization requirements|
|Not persisting session data when required|
|Validation||Failure to implement server-side validation|
|Lack of validation across trust boundaries|
|Not reusing the validation logic|
The visual studio project or the piece of code that handles such transaction should be considered your business layer. If you are placing BeginTransaction/CommitTransaction code in your code behind then you have some serious exercise to do. If you are doing this in your data access layer then you have a chance to separate it out.
- Create a layer (dll) separate from your UI layer (code behind or web project) that handles the transaction.
- Within transaction access the methods of Data Access Layer to keep DAL separate from this layer. Do not call SP directly or queries directly from this layer. Use DAL for that purpose.
- Do not make long wire calls within the transaction like calling web-service. You want to keep your transaction code as fast as possible.
- Keep the business layer running on a server very close to the database server. This way the transaction code will be faster to execute and you will avoid any unnecessary deadlocks.
In one of the projects I had joined earlier team made a mistake by creating web-service over the data access layer and then calling the web-service methods within transaction. This does not solve any problem but rather creates a problem – transaction should make local calls to the database to be able to rollback it.
Some of the ideas that we have talked about earlier for better performance is:
- Try to keep all database transactions run as fast as possible.
- Use Data Entity Objects and Business Objects and do not use Data Set or Data Tables
- Keep the ASP.Net Page View State as small as possible. When not needed, do not keep the EnableViewState=True and specify it to False. Keeping View State smaller helps making the application much faster.
- Create Cache for commonly used database items. There may be some tables/records in database that are not updated often, load them in cache to reduce the database hits.
- Create database indexes appropriately to run the queries faster.
- If you have to use third party web service calls, you may consider using Asynchronous calls.
- Many non-critical items can be called asynchronously to reduce the page response time. For example, logging some entries or making some database auditing entries should be done asynchronously.
The best way to communicate the logical design of an application is to create a visual representation of each component and its corresponding layer. TheFigure 5.3, “Web Application Logical Architecture” figure shows the typical logical design of an ASP.NET MVC web application. Take note how cross-cutting concerns have been separated out into different application services.
Table 5.1. Component Descriptions
|HTML/CSS||Client||The UI elements used to describe the layout and style of the application|
|Security||Client||Security Token (Cookie)|
|Logging||Client||Local service used for logging and monitoring|
|Local Storage||Client||HTML 5 Local Storage (Used for Caching/Offline Storage)|
|Browser Cache||Client||Cache provide by the browser used for storing HTML, CSS, images, etc…|
|View||Web Server||Server Side View used to render HTML|
|Controller||Web Server||Application Controller, handles user input and orchestration|
|Model||Web Server||A collection of classes representing the business domain model for the application|
|Service Layer||Web Server||Service Layer used for encapsulating complex business processes and persistence|
|Repository||Web Server||Data Access Components (Object Relational Mapper)|
|Security||Web Server||Security Service Used for Authenticating and Authorizing Users|
|Logging||Web Server||Application Service used for logging|
|Monitoring||Web Server||Application service used for health monitoring|
|Session/Caching||Data||Application service used for managing transit state|
|External Service||Data||Any external systems the application depends on|