In general, this means evaluating the design for performance, maintainability, extensibility, scalability, availability, recovery, data integrity, and use-case correctness.
Typically, designing a Web application into three logical tiers is sufficient. Creating additional logical tiers is usually an indication of a poor design unless there is a very well thought out reason for the additional tiers. The level at which you can do a performance evaluation of the logical design is typically limited to finding redundancies.
Scalability simply refers to the ability to adapt to the increasing load of the Web site as the number of users increases. This means allowing your application to work well within a Web farm and with load balancers. When reviewing scalability, you should review how state is handled in the logical design. For a typical Web application, you will store some state for users across multiple Web requests. Ensure that your objects can handle being serialized so they can live with any scalability concerns. Serialization usually means that they support the .NET Serialization (for example, supporting ISerializable). Serialization is important because, in a Web application, how objects are cached or communicated can be very different based on a myriad of different configuration options.
Availability and Recoverability Evaluation
High availability is the characteristic of a design that allows for failover and recovery from catastrophic failures. This includes failover ability, reliable transactions, data synchronization, and disaster preparedness.
You should pay attention to in reviewing the logical design is how it will handle authentication and authorization. Depending on your particular requirements, you might use anonymous, forms-based, Microsoft Windows, or a custom authentication solution. The important thing is that you choose an authentication scheme that will scale up with your Web site’s usage. This usually means using anonymous authentication for Web sites that are only publicly available. Anonymous authentication means there will be no way to log on to your Web application.
Authorization to different parts of your Web application is equally fraught with peril. Usually, using role-based security to allow or deny users to different parts of your application is the right approach.
Finally, you must ensure that your logical design protects you against certain types of security attacks that do not require intrusion into your network. The most important to review against are SQL-injection attacks.
The maintainability in the logical design is based on segmenting elements of the logical design into a specific tier of the design. Specifically, each element of the logical design should belong to one (and only one) tier of logical design. Separating those pieces of functionality will ensure that changes to the user interface remain separate from changes to the data layer. Mingling user interface and data tiers inevitably creates code that becomes harder to maintain.
Evaluate the logical design and determine which entities in your design can be built on top of other components. It is important to look for ways to reuse existing code to complete your design instead of building everything from scratch. Using components from inside the .NET Framework as well as in any existing code base will improve the quality of your project.
Data Integrity Evaluation
The decision that you make about what type of concurrency to use—optimistic versus pessimistic— will affect the overall safety and performance of your data tier. Optimistic concurrency implies that data will not have changed between the time of retrieving data and saving changes. Optimistic concurrency generally performs better because there are fewer database locks and logical locks on the data, so more clients can access data concurrently. Alternatively, choosing pessimistic concurrency ensures that the data that a client is changing cannot change during the time that the client is working with that data. In all but the most severe case, optimistic concurrency is the right decision because it scales out better and performs well.
Business Use Case Evaluation
Also at the point of the logical design review, you will need to review the business use cases to ensure that what you have designed continues to meet those needs.
■ Evaluating a logical design for run-time attributes such as performance, scalability, availability, recoverability, security, and data integrity will ensure that the logical design is best suited to fulfil the requirements.
■ Evaluating a logical design for architectural issues such as maintainability and extensibility will ensure that the Web application can efficiently mature as a product.
■ Evaluating a logical design for completeness against the business use cases will ensure that it meets or exceeds the real reason the Web application is being written.