The Architect

Workflow Foundation 4.0 - Microsoft Vizija

2009-10-09T04:37:00Z

These are the materials used on the presentation. I hope i satisfied all attendees with the content of the presentation and the presented demos.

Presentation: here

Demos: here

For more information (and help) for WF, do not hesitate to contact me.

What is really an exception handling in C#

2009-09-09T05:17:00Z

The reason of this post is to explain basic concepts of exception handling, and the idea of, why exception handling in our application. I've seen a lot of examples where exception handling is used in very wrong manner. The exception handling is not supposed to be used to control the application flow or the flow of execution, exception is not used in cases of data formatting or data validation, use of generic exception handler blocks is also not a proper way to implement exception handling.

Exception is an error that occurs at runtime. C# exception handling is managed by four keywords: try, catch, throw, and finally. Some code statements that you want to monitor for exceptions are contained within a try block. If an exception occurs within the try block, it is thrown. We can catch this exception using catch and handle it in some manner. System-generated exceptions are automatically thrown by the runtime system. To manually throw an exception, use the keyword throw. Any code that absolutely must be executed upon exiting from a try block is put in a finally block. When an exception is thrown, it must be caught by some piece of code, somewhere. In general, if our code does not catch an exception, it will be caught by the runtime. The trouble is that the runtime will report an error and terminate the program, which is not nice.

Couple of rules, nice to know:

1. Do not use exception handling for controlling the flow:

- wrong
if (GetUser(userID) == null)
throw new Exception("No User");

- correct
if (GetUser(userID) == null)
return null;

2. Do not use exception handling for data validation

- wrong
try
{ DateTime dt = DateTime.Parse(Console.ReadLine()); // And the data is invalid }
catch (Exception ex)
{ Console.WriteLine(ex.Message); }

- correct

DateTime dt;
if(!DateTime.TryParse(Console.ReadLine(), out dt))
{ Console.WriteLine("Not a valid date."); }

3. Do not use only generic blocks

- wrong
try
{}
catch (Exception ex)
{ Console.WriteLine(ex.Message); }

- correct
try
{}
catch (ArgumentException aex)
{ Console.WriteLine(aex.Message); }
catch (InvalidCastException iex)
{ Console.WriteLine(iex.Message); }
catch (Exception ex)
{ Console.WriteLine(ex.Message); }

In addition, to help a bit about last example, here is the list of commonly used exceptions and some explanation for them.

- ArrayTypeMismatchException: Type of value being stored is incompatible with the type of the array.
- DivideByZeroException: Division by zero attempted
- IndexOutOfRangeException: Array index is out of bounds
- InvalidCastException: A runtime cast is invalid
- OutOfMemoryException: Insufficient free memory exists to continue program execution. For example, this exception will be thrown if there is not sufficient free memory to create an object via new
- OverflowException: An arithmetic overflow occurred
- NullReferenceException: An attempt was made to operate on a null reference—that is, a reference that does not refer to an object
- StackOverflowException: The stack was overrun

Remember that throwing exceptions is of high cost, so use exceptions to handle unexpected scenarios. Try to handle all kind of exceptions for a better logging. What can be done additionally:

- rollback changes done before throwing an exception
- arrange catch blocks to handle most specific to least specific exceptions.
- use Performance counters to understand the impact of exceptions on application.
- use empty throw when catching and re-throwing an exception for preserving call stack pointed to exact error location...

Lazy Load in LINQ to SQL

2008-04-23T22:15:00Z

This is the first post in series regarding LINQ technology and related sub-technologies.
This post will show an example of implementing Lazy load pattern using LINQ to SQL and Visual Studio LINQ Visual Designer.

LINQ To SQL continues to amaze me at the control we have over the lazy loading and pre-fetch of properties and associations.
If we have several columns in the database that are fairly heavy, like binary and NVARCHAR(MAX) columns, duplicating the data in the rows could be very expensive. So how then can we avoid the performance impact associated with heavy columns? Delay load ( lazy load ) them of course.

In the example below, I have specified that the Title column (heavy column) be lazy loaded for testing reasons via the Visual Designer:

Now the Visual Designer changes the Title Field from a basic string field:
private string _Title;

to the following decaration which obviously has lazy loading characteristics that we will talk about later:

private System.Data.Linq.Link<string> _Title;

This means the Title property will be lazy loaded, which means it won't be duplicated above and could really help with performance. Thus, for heavy fields you may want to specify they are always delay loaded. Of course, if we want them to be prefetched, we write the very common code to prefetch Categories and now Title when we need them:

using (BlogDataContext context = new BlogDataContext())
{
     DataLoadOptions options = new DataLoadOptions();
     options.LoadWith<Blog>(c => c.Categories);
     options.LoadWith<Blog>(c => c.Title);
     context.LoadOptions = options;
     Blog blog = context.Blogs.Single<Blog>(c => c.BlogId == 1);
}

Can be usefull.

Original post can be found here.

Refactoring explained

2008-04-22T06:59:00Z

"Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior."
I've found this great link about Refactoring.

Check it out:
Refactoring explained

Additionaly, you can find information about design patterns and anti-patterns.
Very nice to have this site for future reference.

Software architect and his competencies

2008-03-26T05:49:00Z

"The software architect must be well-rounded, posses maturity, vision, and a depth of experience that allows for grasping issues quickly and making educated, critical judgment in the absence of complete information."

Role of the Software Architect

The software architect has overall responsibility for driving the major technical decisions, expressed as the software architecture. This typically includes identifying and documenting the architecturally significant aspects of the system, including requirements, design, implementation, and deployment "views" of the system.
The architect is also responsible for providing rationale for these decisions, balancing the concerns of the various stakeholders, driving down technical risks, and ensuring that decisions are effectively communicated, validated, and adhered to.

Skills of the Software Architect

Experience in both the problem domain, through a thorough understanding of the requirements, and the software engineering domain. The software architect must provide the global vision for the project.
Leadership in order to drive the technical effort across the various teams, and to make critical decisions under pressure and make those decisions stick. To be effective, the software architect and the project manager must work closely together, with the software architect leading the technical issues and the project manager leading the administrative issues. The software architect must have the authority to make technical decisions.
Communication to earn trust, to persuade, to motivate, and to mentor. The software architect cannot lead by decree, only by the consent of the rest of the project. In order to be effective, the software architect must earn the respect of the project team, the project manager, the customer, and the user community, as well as the management team.
Goal-orientation and Pro-activity with a relentless focus on results. The software architect is the technical driving force behind the project, not a visionary or dreamer. The career of a successful software architect is a long series of sub-optimal decisions made in uncertainty and under pressure. Only those who can focus on doing what needs to be done will be successful.

Many Hats of the Software Architect

Visionary – Discovers innovative and novel approaches, translating highly-abstract concerns into tangible opportunities… and results
Manager - Coordinates with all stakeholders to formulate and communicate a practical blueprint
Salesman - Sells the ideas and appropriateness of the solution
Developer – Helps develop POC or pilot to validate solution, patterns, practices, and principles
Leader - Shepherd's from ambiguous and abstract to concrete and practical
Coach – Mentors and coaches others on effective application of industry best practices
Governor – Helps to establish architectural standards and guidelines

Responsibilities of the Software Architect

Abstracts the complexity of a system into manageable models that describes the essence of a system by exposing important details and significant constraints.
Creates and communicates tailored views of the software architecture to appropriate stakeholders at appropriate intervals.
Provides leadership on critical decisions that designate a specific direction for a system in terms of implementation, operations, and maintenance. These decisions usually result in tradeoffs that define key characteristics of the solution, and they must be well documented and easily understood.
Establishes quantifiable objectives that encapsulate quality attributes based upon which the fitness of the architecture is measured.
Proactively leads the implementation during all iterations and monitors the adherence of the implementation to the chosen architecture.
Collaborates with the Project Manager and other key disciplines to prioritize use cases and organize work to drive down risk and encourage strong project control structures.

For quick reference, here's a summary…

Communication

Understand stakeholder needs
Ensure the stakeholder's understand the capabilities and limitations of the architecture
Gain consensus on approach through diplomacy, compromise, and mediation

Business Orientation

Understanding the business/domain
Be aware of financial implications, including costs vs. benefits
Discover opportunities to make trade-offs that maximize value to the customer

Technical Orientation

Quickly grasp the ins-and-outs of the technical and functional domains
Work with the development teams to make sure the target is met
Don't gloss over the details - but don't get buried
Assume accountability for product delivery
Manage scope
Provide technical expertise

Leadership

Think in the abstract - cut through the clutter and quickly arrive at viable solutions.
Know when to stay in the abstract and when to go deep
Engage the teams and build passion for the vision
Demonstrate commitment to continuous improvement - for self and team
Be open minded, innovative, and creative
Delegate

Judgment

Harvest patterns and relationship out of detail and build meaningful models and abstraction
Make good decisions
Focus on the right things

You may also like to have a look at the competencies that are required by the Microsoft Certified Architect (MCA) program.

How to become Microsoft Evangelist

2008-03-19T11:29:05Z

I was wondering for quite some time, what needs to become Microsoft evangelist and who will give me that “title”… is there are exam to pass… what has to be done… work for Microsoft… give feedback to the community…organize events… What?

Some notes from the research I made:

* Presenting/Training .NET development topics
* Working with User Groups to ensure they get adequate support from Microsoft
* Writing sample code
* Working with local influential’s such as MVPs and RD
* Organizing and managing local developer events, conferences

(the most important)
* Microsoft employee ???

If you have more information on this....let's talk about it

MVC Pattern in practice

2008-02-29T08:01:00Z

The idea for this post was a question from my colleague, from yesterday, when I was presenting the architecture of the solution for their project: What is the difference between code implementation in code behind, why putting the code in the controller class, why it is not in the business layer?

The answer to this question is simple, MVC pattern: model - view - controller.

Little explanation on this:

View is the graphical data presentation (outputting) irrespective of the real data processing. View is the responsible for look and feel, some custom formatting, sorting etc. View is completely isolated from actual complex data operations.

Model is responsible for actual data processing, like database connection, querying database, implementing business rules etc. It feeds data to the view without worrying about the actual formatting and look and feel.

Controller is responsible for Notice of action. Controller responds to the mouse or keyboard input to command model and view to change. Controllers are associated with views.

Some benefits:
- Since the Model is completely decoupled from view it allows lot of flexibility to design and implement the model considering reusability and modularity
- It is possible to have development process in parallel for model, view and controller
- This makes the application extensible and scalable

My comments on this issue: there must be a clear and obvious separation of responsibilities, code-behind is view code, never controller/presenter. If you place controller responsibility into the code-behind, good luck with testing. Your lack of cohesion goes up, tight-coupling goes up, extensibility drops and testability drops.
I was trying to explain this, but like always..."please show us code, if you want us to understand.... "

Regular code in their application looks like this: (the code should check if the current product exists in the order, and read all business rules for that product: discount depending on ordered quantity, delivery period for the order depending on the value of the order...)

protected void btnAddProduct_Click(object sender, EventArgs e)
{
    foreach (Product pr in productList)
    {
        if (pr.ProductId == selectedProduct)
        {
            // Add quantity
            pr.Quantity +=1;
            // Apply discount rule
            // if pr.Quantity >2 then pr.Discount=5; if prQuantity > 5 then pr.Discount=10
            // Apply order delivery date rule
            // if order.Amount > 1000$ then order.DeliveryDate = order.StartDate + 3 days
        }
    }
}

Very bad thing to do....

Instead of this, try to transfer your code in the controller class, let her communicate with all business rules, and with the data access.

public static void CheckProduct(Product currentProduct)
{
CheckProduct(currentProduct);
SetOrderDelivery();
}

private void CheckProduct(Product pr)
{
    // CheckProduct existance
    // Call Product Business logic
    // ProductBL.SetDiscount(pr)
}

private void SetOrderDelivery()
{
    // Calculate order amount
    // Call Order Business logic
    // OrderBL.SetDeliveryDate(currentOrder)
}

... finally, call the public method from code-behind:

find appropriate place in your code-behind for creating an instance of the controller...

OrderProcessControler opc = new OrderProcessControler();

...and use it in your event handlers

protected void btnAddProduct_Click(object sender, EventArgs e)
{
opc.CheckProduct(selectedProduct);
}

Note: The controller methods must be placed in different project (class library) for easier scalability of the solution.
Those methods can be modified at any time, deployed separately from the presentation logic.

Hello World!!! :)

2008-02-29T06:33:00Z

As for the beginning of this blog, let me introduce myself. My name is Manas and I work as Solution designer for more than 2 years. I have 9 years of programming experience developing web, windows and mobile applications using .NET technologies.

The main reason for creating this blog is to share the knowledge with all of you, about the options that this technology offers in terms of defining solution architecture, by using design patterns, frameworks, different technologies and other useful practices.

I will try to point some things that should be especially valuable for those architects, designers, and developers who are new to enterprise development in Microsoft environments; this includes both those used to designing and building smaller-sized applications, and those used to design and build enterprise-class applications, web or desktop.

What are the topics that I will be writing on...?
Enterprise architecture, patterns, enterprise application integration, ESB, SOA, OOP, software architecture, architecture frameworks, design principles, requirements analysis and software estimations… don’t forget UML, NET 3.5 stuff, like: LINQ, WWF, WCF, WPF…

Ok… enough for now…stay cool…