MVC Performance

http://encosia.com/a-harsh-reminder-about-the-importance-of-debug-false/

ASP.NET Web Site Performance Improvement

Introduction

Recently, I developed a web application which calls many services and loads a lot of data in every page with a lot of calculation in the background from the database, so the site became slower. Then, I started searching Google to find out a good solution, and got some real good ideas to improve my web application's performance. Here, in this article, I am sharing the tips I applied in the application to improve its performance, and it really works fine now.

Things I Have Done

1. HTTP Compression

HTTP compression is used to compress page content from the server end. It compress HTTP requests and responses, so is a great performance improvement. My project is hosted in Windows Server 2003, and I implemented HTTP compression after reading this article.

2. Disable Possible ViewState

View State allows the page state to be persisted with the client, and it does not require cookies or server memory. View State saves data in a hidden input filed inside a page. Definitely, it is a powerful feature, but the drawback is it increases page size and memory allocation in the server.
So, we should avoid View State where it is not necessary. Especially, in the case of DataGrid controls, we should avoid View State as it loads all the grid data in the page state.
In my application, I disabled View State for most of the controls and pages where View State is not necessary. THis made the page sizes smaller.

3. Changes in the Web.Config File

1. Use page caching:
This will save your page only for a certain amount of time, and the page will be faster to load. But, remember that if your page data changes frequently, it is not a good idea to use page caching.

Collapse | Copy Code

<caching><outputCacheSettings>
    <outputCacheProfiles>
        <add name="cached" duration="600" 
            varyByParam="none" enabled="true"/>
    </outputCacheProfiles></outputCacheSettings></caching>

2. Remove unnecessary httpModules from the web.config:
Collapse | Copy Code

<add name="ScriptModule" 
     type="System.Web.Handlers.ScriptModule, System.Web.Extensions, 
           Version=3.5.0.0, Culture=neutral, 
           PublicKeyToken=31BF3856AD364E35"/><remove name="WindowsAuthentication" /><remove name="PassportAuthentication" /><remove name="AnonymousIdentification" /><remove name="UrlAuthorization" /><remove name="FileAuthorization" />

3. Turn off trace:
Collapse | Copy Code

<trace enabled="false" pageOutput="false" />

4. As I have used membership, I disabled automatic save for profiles:
Collapse | Copy Code

<profile enabled="true" automaticSaveEnabled="false" />

5. Set debug=false:
Collapse | Copy Code

<compilation debug="false">

4. Implement Cache Dependency

Three types of cache dependencies are available:

1. Caching Dependency on cached items
2. Cache Dependency on a file
3. Cache Dependency on SQL

For my project, I used cache dependency on file. For your project, you can choose to use a dependency based on which will be the best fit for your application. Here is a nice example of cache dependency on file.

5. Optimize Stylesheets

It is important to clean up style sheets and remove unnecessary code from style sheets because it increases the load time. Remove all unnecessary classes from style sheets and try to use a single CSS file. In my project, I have used a tool to reduce the size of my stylesheet. I used this service to reduce the size of my CSS file by 20%.

6. Optimize JavaScript

I optimize my JavaScript using this service.

7. JS and CSS File Position

According to the advice from some good articles, I put the CSS file declaration at the top of my master page. It is recommended to call CSS files at the top of a page because the page rendering will progressively become efficient.
I put JavaScript file links at the bottom of the main master file. If we put scripts at the top of the page, then it will cause unnecessarily high load times.

8. server.transfer() Instead of response.redirect()

Where possible, I use server.transfer() instead of response.redirect(). It loads pages faster because it posts only the form, not the complete page.

9. Client-side Script for Validation

For page validation, I use client-side validations instead of postbacks. This way, I reduce round trips in pages.

Points of Interest

There are many more things that can be done to improve the performance of a web application. Given below are the links of some very good articles:

• 10 ASP.NET Performance and Scalability Secrets
• Best Practices to Improve ASP.NET Web Application Performance
• Improve Web Application Performance

History

• 26^th May, 2009: First version.

I plan to add more performance tuning tips in the future.

asp.net validation controls

required field validator
range valida
compare
regular expression
custom validator
validation summary

u can group validators into agroup.
for custom validator , it should inherit a basevalidator class

ASP.net Page Life Cycle

Whenever an ASP.Net page is requested, a particular sequence of events are raised in a sequence called the page execution lifecycle.

1. preinit
2.init
3.initcomplete
4.preload
load
loadcomplete
prerender
render
prerendercomplete
savestatecomplete
unload

Understanding ASP.Net Pages-- dynamic complilation

Understanding dynamic complilation.

when u create an asp.net page, ur creating the source code for a .net class and u r creating an instance of system.web.ui.page class. then the entire contents of  an aps.net page including script, html are complied into a .net class.
when u request a page, ASP.net framework checks for a .net class that corresponds to the page. if the corresponding page does not exist, the framework automamtically compiles the asp.net page into a new class and stores the compiled class in the temporary asp.net files folder located as the

\windows\microsoft.net\framework\v4.0.3023\temporary asp.net files

the next time when a user requests the page , the compiled version is alwyas used until the source code is changed. the compiled version is stored in temporary asp.net files folder until the source code is changed.

When the class is added to the temp folder a dependency is created between the class and the original asp.net page, if the page is modified, the corresponding .ne tclass is deleted.next time any user has requested , the page is automatically compiled into a new .ne tclass.

This process is known as dynamic complilation, which enables asp.net applications to support thousands of users.


  u can precomplie the asp.net application by using aspnet_compiler.exe command line tool.

This process is

MVC Questions

http://www.dotnetobject.com/Thread-MVC-asp-net-interview-question-answer

http://www.wiziq.com/online-tests/32130-asp-net-mvc-interview-questions

http://msprogrammer.serviciipeweb.ro/

http://geekswithblogs.net/DougLampe/archive/2010/11/12/execute-javascript-in-mvc-partial-view.aspx

http://www.dotnetfunda.com/interview/showcatquestion.aspx?category=176

MVC

http://www.dotnetobject.com/Thread-MVC-asp-net-interview-question-answer

The MVC programming model is a lighter alternative to traditional ASP.NET (Web Forms). It is a lightweight, highly testable framework, integrated with all existing ASP.NET features, such as Master Pages, Security, and Authentication.

MVC is a framework for building web applications using a MVC (Model View Controller) design:

• The Model represents the application core (for instance a list of database records).
• The View displays the data (the database records).
• The Controller handles the input (to the database records).

The MVC model defines web applications with 3 logic layers: The business layer (Model logic) The display layer (View logic) The input control (Controller logic)   Benefits: The MVC separation helps you manage complex applications, because you can focus on one aspect a time. For example, you can focus on the view without depending on the business logic. It also makes it easier to test an application. The MVC separation also simplifies group development. Different developers can work on the view, the controller logic, and the business logic in parallel. Web servers will normally map incoming URL requests directly to disk files on the server. For example: an URL request like "http://www.w3schools.com/default.asp" will map directly to the file "default.asp" at the root directory of the server. The MVC framework maps differently. MVC maps URLs to methods. These methods are in classes called "Controllers". Controllers are responsible for processing incoming requests, handling input, saving data, and sending a response to send back to the client.

ASP.Net

http://msdn.microsoft.com/en-us/library/4w3ex9c2(v=vs.100).aspx

Architecture workshop

http://www.bredemeyer.com/architecture_workshop_overview.htm

Software ArchitectureWorkshop Description

Course Overview The term "software architecture" is used both for the high-level structure of a software system, and the related field or discipline. In the workshop, we approach the software architecture discipline from three primary points of view: architecture, answering the question: "what is software architecture?" and introducing architectural patterns, principles and mechanisms. architecting, that is the process of creating an architecture. The major emphasis of the workshop is on learning how to create, validate and update an architecture. architects, focusing on the role and responsibilities of the architect and positioning the architecture role within the organization. Benefits

Software architecture contributes to competitive advantage in two primary ways:

• it provides the technology platform that supports the product characteristics and development processes which differentiate a business from its competitors
• it helps address system complexity.

Software architects are thus poised to play a critical role in an organization’s business success, translating business strategy into an architectural strategy that is the foundation for a stream of products or family of systems. This workshop is designed to provide participants with concepts, techniques and lessons from experience that will help them be more successful in the architect role.

We have considerable experience helping architects and their organizations transition to higher levels of architectural competency. The software architecture workshop integrates extensive real-world architecture experience, and builds on five years of teaching software architecture workshops.

Workshop participants receive a certificate at the end of the class.

Pricing

In-house: Pricing depends on number of students taking the class. Please contact us for details.

US Open Enrollment: The fee for the 4-day workshop is US$2400.00 per student.  

Europe Open Enrollment: The fee for the 4-day workshop is affected by the higher cost structure for running classes in Europe. The fee will be announced when a workshop is scheduled.

Note: We only accept a maximum of 16 participants, so register early to avoid disappointment. Lunches and morning and afternoon snacks will be provided, but workshop participants are responsible for dinners and their own accommodations.

We offer a 10% discount when you enroll 3 or more people from the same company in the same workshop at the same time. (We cannot retroactively apply the discount to people from your company who may already have completed the registration process.)

The price includes the workshop binder with color copies of the slides and notes, and a set of our Architecture Action Guides.

Cancellation Policy

Workshops in the US: We will refund the registration fee less a 5% processing fee if cancellations are made more than 30 days in advance of the workshop start date. Cancellations made 30 days or less from the workshop start date are not refundable. However, student substitutions may be made any time prior to the start of the workshop.

Workshops outside the US: We will refund the registration fee less a 5% processing fee if cancellations are made more than 6 weeks in advance of the workshop start date. Cancellations made within 6 weeks of the workshop start date are not refundable. However, student substitutions may be made any time prior to the start of the workshop.

All Please Note: We reserve the right to cancel or reschedule any workshop if enrollments are below the minimum necessary to cover costs and provide good class participation. This rarely happens, and we will keep registrants informed if enrollments are low enough to cause concern. If we are forced to cancel for any reason (such as major personal calamity including severe sudden illness or injury), our obligation will be limited to a full refund of class enrollment fees or transfer of the registration to a future workshop.

Venue

We will be holding open enrollment Software Architecture Workshops in:

• Eindhoven, The Netherlands, May 7-10, 2012
• Chicago, IL, July 9-12, 2012
• Johannesburg, South Africa, July 23-26, 2012
   

On-site: If  6 or more people from your company would like to attend this class, you may find it more cost effective (taking travel costs into account) to hold the class at your company site.  Please call us at (812) 335-1653 or email training@bredemeyer.com for pricing and schedule.

Suggest a venue: If there is a location and timing that you are particularly interested in, please let us know.

Course Contents

This is a workshop, and small teams work on creating a draft architecture using the Visual Architecting Process. We follow the iterative architecting process, and weave concepts and architecting techniques into the lectures between work sessions. The lecture topics are driven by the concerns that are being addressed at that stage of the architecting process.  This makes it a "non-traditional" format, but it is one that works well as it allows us to work end-to-end through the creation of a draft architecture. 
Software Architecture

In the architecture specification sections, we deal with:

meta-architecture: the architectural vision, style, principles, key communication and control mechanisms, and concepts that guide the team of architects in the creation of the architecture.

architectural patterns: structural patterns such as layers and client/server, and mechanisms such as brokers and bridges.

architecture modeling using the Unified Modeling Language (UML).

architectural views: structural views help document and communicate the architecture in terms of the components and their relationships, and are useful in assessing architectural qualities like extensibility. Behavioral views are useful in thinking through how the components interact to accomplish their assigned responsibilities and evaluating the impact of what-if scenarios on the architecture. Behavioral views are especially useful in assessing run-time qualities such as performance and security. Execution views help in evaluating physical distribution options and documenting decisions.

component specification: components are identified and assigned responsibilities that client components access through "contracted" interfaces. Component interconnections specify communication and control mechanisms and allow component interactions to accomplish system behavior.

key architectural design principles including abstraction, separation of concerns, postponing decisions, and simplicity, and related techniques such as interface hiding and encapsulation, as well as system decomposition principles and good interface design.

See our white paper titled "Software Architecture: Central Concerns, Key Decisions" for an introduction to our approach to architecture.

The Architecting Process

The technical process section is the principal focus of the workshop, and covers:

Architectural requirements: how to elicit and document functional (i.e., behavioral) requirements and non-functional requirements (i.e., system qualities including run-time qualities such as performance and reliability, and development-time qualities such as evolvability/ extensibility and reusability).

System Specification: how to use architectural modeling to decompose the system, evaluate architectural trade-offs, and document the system using different views.

Architecture Validation: how to assess the system in terms of the system requirements.

The organizational process section covers:

Sponsorship: how to gain the support of all levels of management affected by the architecture

Leadership: how to create and lead the architecture team

Consulting: how to assist the developer community in their use of the architecture to ensure its successful adoption and appropriate use.

See the draft chapters of our book titled Software Architecture Action Guide  for an overview of the architecting process that we work through in the workshop.

  

The Role and Responsibilities of the Architect

This section relates the responsibilities and associated skills and attitudes of the architect to the architecting process.

See our white paper titled "The Role of the Architect" for an overview of the architect competency framework that organizes our approach to this section.

Workshop Format

Exercises form a large component of this four-day workshop, which is oriented toward building skills rather than simply exposing students to new concepts. Also, case studies and stories from our experience are used to integrate real-world lessons into the workshop.

Audience

This workshop is designed for architects and senior system design engineers. Managers of architecture teams will also benefit.

Instructor's Background

Either Dana Bredemeyer or Ruth Malan teach the workshop. 

ABOUT BREDEMEYER CONSULTING|

Bredemeyer Consulting specializes in training and mentoring software architects. We typically work with architecture teams, providing training and mentoring to accelerate their creation or migration of an architecture. However, we do offer a limited number of Software Architecture Workshops for open enrollment.

Model Your Data Hierarchies With SQL Server 2008

http://msdn.microsoft.com/en-us/magazine/cc794278.aspx

What Does an Architect Do?

http://www.designpatternsfor.net/default.aspx?pid=5

http://www.designpatternsfor.net/default.aspx?pid=75

http://www.hanselman.com/blog/WhatGreatNETDevelopersOughtToKnowMoreNETInterviewQuestions.aspx
 

What Does it Mean to be a Software Architect? - Part III

By: Rob Daigneau   Created: 11/17/2006   Last Update: 1/7/2007

Some people equate software architecture with the detailed design of things like services, classes, database tables, and so forth. In practice, software architecture actually encompasses much more, and the role of the architect oftentimes involves aspects of other competencies. Unfortunately, for organizations that are unfamiliar with the function of architecture, problems can arise when the architect’s daily work leads them to become involved in functions that are traditionally performed by project managers, business analysts, and developers. This article takes an in depth look at some of the things architects do, where problems can arise between architects and other groups within an organization, and ways that the architect can become effective in their role.

What Does an Architect Do?

In my article What Does it Mean to be a Software Architect – Part I, I offered a very simple starting definition for an architect:

"1. A person who designs software systems and advises in the design of such systems. 2. A person who designs and guides a plan or undertaking related to software systems design."

I must emphasize that this was only a starting point. The follow-up question to this definition might be, “What do we mean by design, guide, and plan?” In response to this question, here are a few things that the architect might provide guidance and plans for:

• The Creation, Capture, and Management of Business Requirements
• Project Management Plans
• Architecture Plans

The Creation, Capture, and Management of Business Requirements

Software architects oftentimes play an integral role in the elicitation and organization of business requirements. The premise here is that the purpose of architecture is to ensure that the business needs are fulfilled, and the resulting architecture must be directly influenced by the business requirements. Architects should, at the very least, be well-informed concerning the scope of business requirements to be addressed, must understand how product features map back to business requirements and their associated benefits, and must also be kept up-to-date concerning the evolution of the functional specifications for the proposed software product.
In many cases, the architect may perceive a need to provide consultation concerning the most effective ways to capture and manage these requirements. The reason that the architect may want to step in to provide such consultation is because they usually have gained significant experience as business analysts and have learned the right types of questions to ask that would in turn reveal the most beneficial architectural approaches. Furthermore, effective architects know specifically what information software developers require in order to do their jobs and can help guide the capture of these specifications in such a way that the specs both confirm what the business users want, and also serve as practical tools that developers can refer to when moving forward with their design and development efforts.
Architects may also need to work with the analysts to manage the expectations of project stakeholders. While the analysts work closely with the business to define the product scope and requirements, oftentimes it is the architect that helps all parties understand the feasibility of achieving certain project goals given an understanding of the staffing, scheduling, funding, and technology constraints. The architect can help the team understand what the selected technologies are capable of, how they might need to be extended or customized, and the related work effort that is implied by the functional specifications.
I would suggest that the best software architects are good businessmen (or women) and also happen to be excellent technologists.

Project Management Plans

Software architects typically have a unique perspective on the factors that impact the project’s schedule, budget, risks, and required resources. These factors include aspects of the solution design (discussed in the following section), the true nature of the business requirements, and the most effective means to staff development efforts to build what is described in the solution architecture.
Given this unique insight, I feel that software architects have an unwritten duty to provide consultation on how project plans, budgets, and staffing plans might be structured to achieve the goals of the architecture. The problem is that this consultation may be unsolicted and unwelcome, so be very careful in the way you present your suggestions.

Architecture Plans

This is the key concern of the architect. Here are some components of a typical architecture plan:

1. Non-functional or "Technical Requirements. These are sometime referred to as the system's "Quality of Service Attributes". A description of typical non-functional requirements can be found here under the heading of "Shared Goals".
2. A definition of the principles, standards, and guidelines that will guide the architecture. These items provide a compass or vision for the creation of everything that follows. 
3. The creation of a solution design intended to achieve the desired business requirements. The architect may be responsible or accountable for any of these, or might simply provide oversight on ...
   • The creation of Logical Models
   • The software design (i.e. logical and physical designs of services, classes, interfaces, database tables; the use of layers and patterns; the use of centralized vs. distributed logic; etc.)
   • The evaluation and selection of various technologies used to achieve certain functional or technical requirements
   • Trade-off decisions (re: Architectural Decisions and Their Consequences) that affect software design or the selection of various technologies
   • Application integration strategies
   • Physical deployment strategies (i.e. the design of the "Execution Architecture" upon which the components of the solution will run) 
   • "Buy, Borrow, or Build" decisions

Recommendations on product release strategies and versioning approaches. This may involve roadmaps that show how older versions of products evolve into or run in parallel with new versions of products.

The design of logical environments (e.g. design, integration, test/QA, staging, production), and the processes that govern the flow of software deliverables from one environment to the next. This also typically includes capacity planning requirements (i.e. recommendations concerning the sizing and deployment of hardware resources so that they will properly handle the projected user loads and disk requirements), and recommendations for the specific software and hardware to be used along with associated configurations for each logical environment.

Strategies to ensure proper governance of IT assets (re: IT Governance: How Top Performers Manage IT Decision Rights for Superior Results).

The definition of principles, standards, and guidelines for design, coding, unit-testing, and build processes for the project or the organization.

The evaluation and selection of development related tools and technologies (i.e. integrated development environments like Visual Studio Team System, source-code management, productivity tools, 3rd party components and libraries, etc.), and the definition of related processes (e.g. merge/branch processes for source-code management).

Data conversion requirements. This is an oftentimes forgotten necessity when migrating from older versions of products to newer ones. Architects must determine if data must be converted, and how that conversion will take place.

Depending upon what type of architect you are, you may or may not be involved in the coding and unit-testing of some of the more complex areas of the system. These areas are typically foundational in nature (e.g. base class libraries, frameworks, cross-cutting concerns like authentication and authorization, encryption, localization, diagnostics and logging, exception management, interprocess communications, etc.).

Whose Job is it Anyway?

It’s not unusual for architects to encounter resistance or incur a fair amount of angst in organizations that have either launched an independent architecture team or are unfamiliar with the function of architecture. Given that the architect’s unique perspective and experience can not only help analysts capture more useful business requirements but can also be leveraged to develop effective project plans, the architect, in the course of doing what they think ought to be done, may unwittingly wander into territories where they are not welcome. The chilly reception these architects might encounter is oftentimes attributable to the fact that the role of the architect may not be fully understood by project managers or analysts. These individuals might feel a bit territorial over their turf, and may assume that the architect is trying to exert control in areas which are not within the domain of their primary responsibilities. At other times the architect may be overzealous in his or her efforts to help. These architects may, through their bold or outspoken suggestions, lead some to think that the architect perceives them as being less than capable. In all of these scenarios, the architect must keep their social antennae well tuned, and adapt their approach given the unique personalities on the team.
There’s also a grey area surrounding who owns various aspects of the solution design. Traditionally, this has been the province of the development teams, but in many organizations separate architecture teams are created in order to ensure that the design of software products really does contribute to the attainment of the business objectives outlined in the organization’s strategy and tactics. Independent architecture teams might also be formed to enforce governance around common mission-critical software functions. The purpose of this governance is to ensure that key components of the software systems are properly managed so that they will continue to work properly and serve the business need over time even when change is introduced. The challenge to the architect is to show the development teams that they’re really there to help, not to put a damper on things.
When architects come onto the scene, development teams are oftentimes concerned that they may lose control or be slowed down by bureaucratic processes. It is true that the development groups might need to cede some control or at the very least collaborate in a few areas (e.g. the solution design) where they had sole discretion in the past. There is also a danger that governance processes, like design and code reviews, if done improperly, can put the brakes on the speed of development. However, if done correctly, governance processes can actually improve the speed of development by catching design mistakes earlier in the project, thus preventing costly downstream corrections. Once again, the architect must gain the trust of the developers, and this can take some time. I’ve found that the best thing to do is to become a real member of the development team and be more collaborative in your approach. Dictatorial and “I know better than you” approaches never work very well if you want to gain trust.
Developers may feel that their importance in the organization diminishes when architects become involved. Nothing could be further from the truth. Even with architects in the picture, developers have a ton of work to do including coding the applications, conducting code reviews, creating and executing unit tests, documenting the software, and so on. Developers still have a huge opportunity to be creative with their code, and I would also suggest that developers be given responsibility for the detailed design of classes and such, with a bit of coaching from time to time from the architect. In the end, the development organizations are responsible for delivering the software product, so it is usually wise to let the developer teams create their own software development plans and execute upon them.
Another concern from developers is that they may see architects as ivory tower academics with no practical real-world experience who attempt to foist their ideas upon the developer teams. This can be because architects tend to talk about very abstract things like patterns, draw a lot of pictures, and may not code as much as the developers do. It is true that some architects haven’t come up through the coding ranks. I would agree that the best architects do have real world experience and should have cranked out a lot of code in their time. Here again, the architect needs to build trust, and this takes time, patience, and a commitment to working as a collaborative team member.
Architects might feel that they have to do all of the work involved in producing Architecture plans, but the best results are usually achieved when the work is shared and the Architect serves as a guide, overseer, and mentor. For example, while the architect might provide an outline for the logical layers and high-level designs, it’s usually best if detailed design (including physical design) is left to the developers. The architect can, in this scenario, provide advice concerning design approaches that will be beneficial or problematic in the long run, and can also give ideas about the trade-offs that might go along with such decisions. The goal of the architect should be to help all developers become more adept at software design, and to learn the techniques used to develop the artifacts in the Architecture plan.
Here’s an acronym you can use to help you determine "whose job it is" ... RACI:

• Responsible: The person(s) who performs a given task

• Accountable: The person(s) who must answer for the results of given tasks. This person usually signs off on the work performed by those who are responsible for certain tasks

• Consulted: The person(s) whose input should or must be solicited

• Informed: The person(s) who should be provided status on the task, but may not need to be consulted

When there are questions about your role as an architect, it’s definitely a good thing to talk openly about who is responsible, accountable, consulted, and informed. All too often, architects, project managers, analysts, and development leads make innocent assumptions on these things, and problems in team relationships inevitably follow.

Lessons for the Architect from the School of Life

Life provides the best lessons. I’ve made a lot of mistakes over the years, and admittedly still do. Here are a few pearls of wisdom I’ve picked up along the way; sometimes I even remember to live by these ideas:

• The Hard Skills are the Soft Skills. Technology is the easy part; working well with people is the real challenge and reward.

• Architects achieve better results when they think of themselves as servants whose mission it is to help others to be successful.

• Know who your constituents are, and learn to become more aware of when you might be stepping into their territory. Recognize that it can be natural for people to be somewhat territorial over things; consider how you might feel if an architect came on the scene providing direction to you on things you’ve been responsible for.

• Regardless what people say (about teamwork), few people want to have dependencies on others, and in some organizations collaboration only occurs when the individuals are coerced from above. If groups or individuals are resistant to you, it might be because they perceive that you might be an obstacle for them, even if you don't intend any such thing.

• Architects need to be extremely careful when offering criticism, but must be prepared to receive endless criticism. If you don’t like being questioned, then architecture might not be for you.

• Don’t be attached to showing people the right way to do things.

• You don’t always have to be right. Know when to let things go; not everything is of equal importance.

• Architects tend to have a much harder time achieving success when they seek glory. Things tend to work out much better if you let others have the credit. People will know, in the end, that you an integral force that facilitated successful efforts.

• Know the boundaries of your authority. If your role is to consult, then all you can do is suggest certain approaches. In such a scenario you would be wise to not insist that things be done a certain way.

• Just as parents sometimes need to let children go their own way and learn through their mistakes, architects need to become comfortable with letting their constituents make mistakes, unless of course a catastrophe seems to be in the making. If your constituents want to do their own thing against your best advice, you would be wise to be supportive of them.

• When making recommendations, architects should provide real evidence and data to back up their suggestions. Don’t offer unfounded claims or simply make emotional appeals.

• Avoid using email or Instant Messaging to discuss potentially contentious or sensitive issues. It's all too easy to be misunderstood when using the written word.

• Architects must be keenly aware of the politics of the organization, but should not get involved. Be loyal to all your constituents, don’t play sides, and never ever gossip.

• Architects are oftentimes so eager to help or share their ideas that they forget to shut up. Architects must practice how to listen more than they talk.

• Architects must develop high degrees of patience. Not everyone has similar backgrounds or experience, and it can take a long time to impart new ways of looking at things.

Related Articles:

• Escape Metropolis: Bridging the Divide Between Developers and Architects
• What do Architects do Anyway?
• LLogical and physical designs

The 4+1 Architectural View Model

http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf

Unit-of-Work-Pattern and repository Pattern

Best for difference and hybrid of Unit of work and repository 

http://robrich.org/archive/2012/04/18/Design-Patterns-for-data-persistence-Unit-of-Work-Pattern-and.aspx


Data persistence patterns

http://msdn.microsoft.com/en-us/magazine/dd569757.aspx

Design Patterns

Structural
Behavioural
Creational

http://www.accelebrate.com/microsoft_dotnet/dotnet_designpatterns_training.htm

Structural:
Structural design pattern emphasizes upon the overall structure of classes and objects in the system either by doing class inheritance or by composing objects into larger structures using object composition.


• Day 1
• Pattern Overview
• Need
• Features
• Categories
• Creational Pattern
• Abstract Factory
• Builder
• Factory Method
• Prototype
• Singleton
• Structural Pattern
• Adapter
• Bridge
• Day 2
•
• Composite
• Decorator
• Faade
• FlyWeight
• Proxy
• Behavioral Pattern
• Chain of Responsibility
• Command
• Interpreter
•
• Day 3
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template
• Visitor
 

Data Modeling With The Entity Framework

http://msdn.microsoft.com/en-us/magazine/cc700331.aspx

Transactions

http://msdn.microsoft.com/en-us/magazine/cc663023.aspx

Difference between an abstract class and interface

http://www.codeproject.com/Articles/11155/Abstract-Class-versus-Interface

Interface is not a class. Its an entity with word interface which provides a contract of methods without any implementation. Its is used only for inheritance


++++++++++++++++++

http://msdn.microsoft.com/en-us/library/9w2ctx1s%28v=vs.71%29.aspx

An interface describes the methods, properties, and events that a class needs to implement, and the type of parameters each member needs to receive and return, but leaves the specific implementation of these members up to the implementing class.

An abstract class is a class that cannot be instantiated itself; it must be inherited. Some or all members of the class might be unimplemented, and it is up to the inheriting class to provide that implementation. Members that are implemented might still be overridden, and the inheriting class can still implement additional interfaces or other functionality


Polymorphism is the ability for classes to provide different implementations of methods that are called by the same name.

When to Use Inheritance-Driven Polymorphism

The foremost use of inheritance is to add functionality to an existing base class. Programmer productivity is much greater when you start with a framework of fully debugged base classes, and methods can be incrementally added to base classes without breaking versioning.
You may also wish to use inheritance when your application design includes several related classes that must share identical implementation for certain common functions. The overlapping functionality can be implemented in a base class, from which the classes used in the application can be derived. An abstract class combines features of both inheritance and implementation, and may be useful when elements of each are needed.

Polymorphism Through Abstract Classes

Abstract classes provide features of both inheritance and interface implementation. An abstract (MustInherit in Visual Basic) class is a class that cannot be instantiated, and must be implemented in an inheriting class. It may contain methods and properties that are already implemented, but it may also incorporate unimplemented procedures which must be implemented in the inheriting class. This allows you to provide an invariant level of functionality in some methods of your class, while leaving flexibility options open for other procedures. An additional benefit of abstract classes is that when new versions of your component are required, additional methods may be added to the base class as needed, whereas interfaces must remain invariant.

When to Use Abstract Classes

An abstract class is useful when you need a group of related components to incorporate a set of methods with identical functionality, but also require flexibility in the implementation of other methods. Abstract classes are also valuable when versioning issues are anticipated, because the base class remains flexible and easily modified. For details, see Recommendations for Abstract Classes vs. Interfaces.

SQL Server Performance tuning

http://msdn.microsoft.com/en-us/library/ms178100%28v=sql.100%29.aspx

Database Engine Tuning Advisor

http://msdn.microsoft.com/en-us/library/ms166575%28v=sql.100%29.aspx

The Database Engine Tuning Advisor enables you to tune databases for improved query processing. Database Engine Tuning Advisor examines how queries are processed in the databases you specify and then it recommends how you can improve query processing performance by modifying physical design structures such as indexes, indexed views, and partitioning.

It replaces the Index Tuning Wizard from Microsoft SQL Server 2000, and offers many new features. For example, Database Engine Tuning Advisor provides two user interfaces: a graphical user interface (GUI) and the dta command prompt utility. The GUI makes it easy to quickly view the results of tuning sessions, and the dta utility makes it easy to incorporate Database Engine Tuning Advisor functionality into scripts for automated tuning. In addition, Database Engine Tuning Advisor can take XML input, which offers more control over the tuning process. For more information about Database Engine Tuning Advisor new features, see Database Engine Tuning Advisor Features.

SQL Server Code Review Checklist

http://www.mssqltips.com/sqlservertip/1303/sql-server-code-review-checklist/

http://www.mssqltips.com/sqlservertip/1301/sql-server-code-deployment-best-practices/

Inheritance

A class will inherit the members of its direct base class. The upshot of inheritance is that a class will

implicitly contain all members of its direct base class, except for any instance constructors, finalizers,

and static constructors.

A derived class can add new members to those it inherits, but it cannot remove the definition of an

inherited member.

Instance constructors, finalizers, and static constructors are not inherited, but all other members are.

A class can declare virtual methods, properties, indexers, and events, and derived classes can override

the implementation of these function members.

Members inherited from a constructed generic type are inherited after type substitution.

Generics

Abstract Class Design

Because abstract classes should never be instantiated, it is important to correctly define their constructors. It is also important to ensure that the functionality of your abstract class is correct and easily extended. The following guidelines help ensure that your abstract classes are correctly designed and work as expected when implemented.

Do not define public or protected internal (Protected Friend in Visual Basic) constructors in abstract types.
Constructors with public or protected internal visibility are for types that can be instantiated. Abstract types can never be instantiated.

Do define a protected or an internal constructor in abstract classes.
If you define a protected constructor in an abstract class, the base class can perform initialization tasks when instances of a derived class are created. An internal constructor prevents the abstract class from being used as the base class of types that are not in the same assembly as the abstract class.

Do provide at least one concrete type that inherits from each abstract class that you ship.
This practice helps library designers locate problems or oversights in the abstract class design. It also means that for high-level scenarios where developers might not understand abstract classes and inheritance, they can use the concrete class without having to learn these concepts. For example, the .NET Framework provides the abstract classes WebRequest and WebResponse to handle sending requests to, and receiving replies from a Uniform Resource Identifier. As one of several concrete implementations for these abstract classes, the Framework includes the HttpWebRequest and HttpWebResponse classes, which are HTTP-specific implementations of the abstract classes.

Abstract Class

An abstract class cannot be instantiated. The purpose of an abstract class is to provide a common definition of a base class that multiple derived classes can share.

Abstract classes may also define abstract methods. This is accomplished by adding the keyword abstract before the return type of the method.
Abstract methods have no implementation, so the method definition is followed by a semicolon instead of a normal method block. Derived classes of the abstract class must implement all abstract methods. When an abstract class inherits a virtual method from a base class, the abstract class can override the virtual method with an abstract method. For example:

VB

C#

C++

F#

JScript

View ColorizedCopy to ClipboardPrint

// compile with: /target:library
  
  public class D
  {
      public virtual void DoWork(int i)
      {
          // Original implementation.
  
      }
  }
  
  public abstract class E : D
  {
      public abstract override void DoWork(int i);
  }
  
  public class F : E
  {
      public override void DoWork(int i)
      {
          // New implementation.
  
      }
  }

Define Abstract Properties 

 An abstract property declaration does not provide an implementation of the 
property accessors -- it declares that the class supports properties, but leaves 
the accessor implementation to derived classes. 

public abstract double Area
      {
          get;
      }
 

Static Class and Singleton Pattern

Static classes and singletons both provide sharing of redundant objects in memory, but they are very different in usage and implementation.

Static Class - You can not create the instance of static class.
Singleton pattern - you can create one instance of the object and reuse it.
Static classes- are loaded automatically by the .NET Framework common language runtime (CLR) when the program or namespace containing the class is loaded.
Singleton instance is created for the first time when the user requested.
Static Class class cannot have constructor.
singleton class can have constructor.

++++++++++++++++++
static members can operate only on static data and call static methods of the

defining class. If you attempt to make use of nonstatic class data or call a nonstatic method of the class within a

static member’s implementation, you’ll receive compile-time errors.Singleton has a private constructor

Use singleton as parameter.

Static Class - You can not create the instance of static class.

Singleton pattern - you can create one instance of the object and reuse it.

Static classes- are loaded automatically by the .NET Framework common language runtime (CLR) when the program or namespace containing the class is loaded.

Singleton instance is created for the first time when the user requested.

Static Class class cannot have constructor.

singleton class can have constructor.

http://www.dotnetspider.com/forum/145836-Difference-between-Static-class-Singleton-Instance.aspx


Introducing the Singleton Pattern
Our ideal solution is called the singleton design pattern. Here is an implementation of a singleton that I will use. As you know, a singleton is a single-instance object. It is highly efficient and very graceful. Singletons have a static property that you must access to get the object reference.


Here we looked at some aspects of the singleton design pattern in the C# language. Singletons allow you to reuse code and control object state much easier. This improves code-sharing, and can result in a far cleaner body of code. With less code, your programs will usually have fewer bugs and will be easier to maintain.

Types of Indexes on tablels

The following table lists the types of indexes available in SQL Server and provides links to additional information.

Index type	Description	Additional information
Clustered	A clustered index sorts and stores the data rows of the table or view in order based on the clustered index key. The clustered index is implemented as a B-tree index structure that supports fast retrieval of the rows, based on their clustered index key values.	Clustered Index Design Guidelines Clustered Index Structures
Nonclustered	A nonclustered index can be defined on a table or view with a clustered index or on a heap. Each index row in the nonclustered index contains the nonclustered key value and a row locator. This locator points to the data row in the clustered index or heap having the key value. The rows in the index are stored in the order of the index key values, but the data rows are not guaranteed to be in any particular order unless a clustered index is created on the table.	Nonclustered Index Design Guidelines Nonclustered Index Structures
Unique	A unique index ensures that the index key contains no duplicate values and therefore every row in the table or view is in some way unique. Both clustered and nonclustered indexes can be unique.	Unique Index Design Guidelines
Index with included columns	A nonclustered index that is extended to include nonkey columns in addition to the key columns.	Index with Included Columns
Indexed views	An index on a view materializes (executes), the view and the result set is permanently stored in a unique clustered index in the same way a table with a clustered index is stored. Nonclustered indexes on the view can be added after the clustered index is created.	Designing Indexed Views
Full-text	A special type of token-based functional index that is built and maintained by the Microsoft Full-Text Engine for SQL Server. It provides efficient support for sophisticated word searches in character string data.	Full-Text Indexes
Spatial	A spatial index provides the ability to perform certain operations more efficiently on spatial objects (spatial data) in a column of the geometry data type. The spatial index reduces the number of objects on which relatively costly spatial operations need to be applied.	Spatial Indexing Overview
Filtered	An optimized nonclustered index, especially suited to cover queries that select from a well-defined subset of data. It uses a filter predicate to index a portion of rows in the table. A well-designed filtered index can improve query performance, reduce index maintenance costs, and reduce index storage costs compared with full-table indexes.	Filtered Index Design Guidelines
XML	A shredded, and persisted, representation of the XML binary large objects (BLOBs) in the xml data type column.	Indexes on XML Data Type Columns

 

Indexing Tables

An index is an on-disk structure associated with a table or view that speeds retrieval of rows from the table or view. An index contains keys built from one or more columns in the table or view. These keys are stored in a structure (B-tree) that enables SQL Server to find the row or rows associated with the key values quickly and efficiently.
A table or view can contain the following types of indexes:

• Clustered
  
  
  • Clustered indexes sort and store the data rows in the table or view based on their key values. These are the columns included in the index definition. There can be only one clustered index per table, because the data rows themselves can be sorted in only one order.
    
    
  • The only time the data rows in a table are stored in sorted order is when the table contains a clustered index. When a table has a clustered index, the table is called a clustered table. If a table has no clustered index, its data rows are stored in an unordered structure called a heap.
    
• Nonclustered
  
  
  • Nonclustered indexes have a structure separate from the data rows. A nonclustered index contains the nonclustered index key values and each key value entry has a pointer to the data row that contains the key value.
    
    
  • The pointer from an index row in a nonclustered index to a data row is called a row locator. The structure of the row locator depends on whether the data pages are stored in a heap or a clustered table. For a heap, a row locator is a pointer to the row. For a clustered table, the row locator is the clustered index key.
    
    
  • You can add nonkey columns to the leaf level of the nonclustered index to by-pass existing index key limits, 900 bytes and 16 key columns, and execute fully covered, indexed, queries.

How Indexes Are Used by the Query Optimizer

Well-designed indexes can reduce disk I/O operations and consume fewer system resources therefore improving query performance. Indexes can be helpful for a variety of queries that contain SELECT, UPDATE, DELETE, or MERGE statements. Consider the query SELECT Title, HireDate FROM HumanResources.Employee WHERE EmployeeID = 250 in the AdventureWorks database. When this query is executed, the query optimizer evaluates each available method for retrieving the data and selects the most efficient method. The method may be a table scan, or may be scanning one or more indexes if they exist.

When performing a table scan, the query optimizer reads all the rows in the table, and extracts the rows that meet the criteria of the query. A table scan generates many disk I/O operations and can be resource intensive. However, a table scan could be the most efficient method if, for example, the result set of the query is a high percentage of rows from the table.

When the query optimizer uses an index, it searches the index key columns, finds the storage location of the rows needed by the query and extracts the matching rows from that location. Generally, searching the index is much faster than searching the table because unlike a table, an index frequently contains very few columns per row and the rows are in sorted order.

The query optimizer typically selects the most efficient method when executing queries. However, if no indexes are available, the query optimizer must use a table scan. Your task is to design and create indexes that are best suited to your environment so that the query optimizer has a selection of efficient indexes from which to select. SQL Server provides the Database Engine Tuning Advisor to help with the analysis of your database environment and in the selection of appropriate indexes.

Data Integrity basics

The first step in specifying the domains of a table is to determine column data types. A domain is the set of all allowed values in a column. A domain includes not only the concept of enforcing data types, but also the values allowed in the column. For example, the domain for the Color column of the Production.Product table includes the data type nvarchar, and a size limit of 15 characters.

Null Values

Columns can either accept or reject null values. NULL is a special value in databases that represents the concept of an unknown value. NULL is different from a blank character or 0. Blank is actually a valid character, and 0 is a valid number. NULL just represents the idea that we do not know what this value is. NULL is also different from a zero-length string. If a column definition contains the NOT NULL clause, you cannot insert rows that have the value NULL for that row. If the column definition has only the NULL keyword, it accepts null values.

Allowing null values in a column can increase the complexity of any logical comparisons that use the column. The ISO standard states that any comparison against NULL does not evaluate to TRUE or FALSE, it evaluates to UNKNOWN. This introduces three-value logic to comparison operators, which can be difficult to manage correctly.

Constraints, Rules, Defaults, and Triggers

</ 2003 authoring ddue.schemas.microsoft.com xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" 5:content>

Table columns have properties besides data type and size. These other properties are an important part of guaranteeing the integrity of the data and the referential integrity of the tables in a database:

• Data integrity refers to each occurrence of a column having a correct data value. The data values must be of the right data type and in the correct domain.
  
  
• Referential integrity indicates that the relationships between tables have been correctly maintained. Data in one table should only point to existing rows in another table and not point to rows that do not exist.
  

The following objects are used to maintain both types of integrity:

• Constraints
  
  
• Rules
  
  
• Defaults
  
  
• DML Triggers

</ 2003 authoring ddue.schemas.microsoft.com 5:content>

Data Integrity

Enforcing data integrity guarantees the quality of the data in the database. For example, if an employee is entered with an employee ID value of 123, the database should not permit another employee to have an ID with the same value.
Entity Integrity

Entity integrity defines a row as a unique entity for a particular table. Entity integrity enforces the integrity of the identifier columns or the primary key of a table, through UNIQUE indexes, UNIQUE constraints or PRIMARY KEY constraints.

Domain Integrity

Domain integrity is the validity of entries for a specific column. You can enforce domain integrity to restrict the type by using data types, restrict the format by using CHECK constraints and rules, or restrict the range of possible values by using FOREIGN KEY constraints, CHECK constraints, DEFAULT definitions, NOT NULL definitions, and rules.

Referential Integrity

</ 2003 authoring ddue.schemas.microsoft.com xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" 5:content>

Referential integrity preserves the defined relationships between tables when rows are entered or deleted. In SQL Server, referential integrity is based on relationships between foreign keys and primary keys or between foreign keys and unique keys, through FOREIGN KEY and CHECK constraints. Referential integrity makes sure that key values are consistent across tables. This kind of consistency requires that there are no references to nonexistent values and that if a key value changes, all references to it change consistently throughout the database.

When you enforce referential integrity, SQL Server prevents users from doing the following:

• Adding or changing rows to a related table if there is no associated row in the primary table.
  
  
• Changing values in a primary table that causes orphaned rows in a related table.
  
  
• Deleting rows from a primary table if there are matching related rows.

For example, with the Sales.SalesOrderDetail and Production.Product tables in the AdventureWorks database, referential integrity is based on the relationship between the foreign key (ProductID) in the Sales.SalesOrderDetail table and the primary key (ProductID) in the Production.Product table. This relationship makes sure that a sales order can never reference a product that does not exist in the Production.Product table.

User-Defined Integrity

</ 2003 authoring ddue.schemas.microsoft.com xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" 5:content>

User-defined integrity lets you define specific business rules that do not fall into one of the other integrity categories. All the integrity categories support user-defined integrity. This includes all column-level and table-level constraints in CREATE TABLE, stored procedures, and triggers.

</ 2003 authoring ddue.schemas.microsoft.com 5:content>

</ 2003 authoring ddue.schemas.microsoft.com 5:content>

Online Transaction Processing Database Design

Online transaction processing database applications are optimal for managing changing data. These applications typically have many users who are performing transactions at the same time that change real-time data. Although individual requests by users for data usually reference few records, many of these requests are being made at the same time. Common examples of these types of databases are airline ticketing systems and banking transaction systems. The primary concerns in this kind of application are concurrency and atomicity.

Concurrency controls in a database system guarantee that two users cannot change the same data, or that one user cannot change a piece of data before another user is finished with it. For example, if you are talking to an airline ticket agent to reserve the last available seat on a flight and the agent starts the process of reserving the seat in your name, another agent should not be able to tell another passenger that the seat is available.

Atomicity guarantees that all the steps in a transaction are completed successfully as a group. If any step fails, no other steps should be completed. For example, a banking transaction may involve two steps: taking funds out of your checking account and putting them into your savings account. If the step that removes the funds from your checking account succeeds, you want to make sure that the funds are put into your savings account or put back into your checking account.

Online Transaction Processing Design Considerations

</ 2003 authoring ddue.schemas.microsoft.com xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" 5:content>

Transaction processing system databases should be designed to promote the following:

• Good data placement
  
  I/O bottlenecks are a big concern for OLTP systems, because of the number of users modifying data all over the database. When you design a database, determine the likely access patterns of the data and combine frequently accessed data together. Use filegroups and RAID (redundant array of independent disks) systems to help in this.
  
  
• Short transactions to minimize long-term locks and improve concurrency
  
  Avoid user interaction during transactions. Whenever possible, run a single stored procedure to process the whole transaction. The order in which you reference tables within your transactions can affect concurrency. Put references to frequently accessed tables at the end of the transaction to minimize the duration that locks are held.
  
  
• Online backup
  
  OLTP systems are frequently characterized by continuous operations in which down time is kept to an absolute minimum. That is, they operate 24 hours a day, 7 days a week. Although the SQL Server Database Engine can back up a database while it is being used, schedule the backup process to occur during times of low activity to minimize the effects on users.
  
  
• High normalization of the database
  
  Reduce redundant information to increase the speed of updates and improve concurrency. Reducing data also improves the speed of backups, because less data has to be backed up.
  
  
• Minimal or no historical or aggregated data
  
  Data that is rarely referenced can be archived into separate databases, or moved out of the heavily updated tables into tables that contain only historical data. This keeps tables as small as possible, and improves backup times and query performance.
  
  
• Careful use of indexes
  
  Indexes must be updated every time a row is added or modified. To avoid over-indexing heavily updated tables, keep indexes narrow. Use the Database Engine Tuning Advisor to design your indexes.
  
  
• Optimum hardware configuration to handle the large numbers of concurrent users and quick response times required by an OLTP system

</ 2003 authoring ddue.schemas.microsoft.com 5:content>