Stepping into Software Development World

The Enterprise Middleware Age

2011-06-02T00:11:00.001+03:00

Since the growth of the web distributed models have become the de facto standard of the corporate software industry. N -tiered models allowed for the simple decoupling of layers both physically and conceptually. This is so because of the frameworks available that supports their individual technical purposes, as well as because of the lower cost of hardware needed to house these systems. The web model took a firm architectural hold in the early 2000s. Even systems requiring or preferring the use of thick client installations shifted toward an application server to handle business rules external to the database. Yet as these distributed models grew, another technical dilemma surfaced: interoperability.

The world was smaller now, and systems were being developed with communications in mind. Systems were expected to transmit data between servers and PCs to perform even the simplest of business tasks. Businesses increased the number of applications they built to support business needs, which now needed to communicate with each other to share logic and services. Even the exchange of data had now complicated a bit as each application required a number of dedicated data servers for redundancy and high availability. Which server was the right one to use? How would a process running on server X know how to access logic from a class on server Y? The answer was the creation of enterprise middleware.

Enterprise middleware can be considered any model that handles the communication of computers between platforms and systems. The job of middleware software is to abstract the consuming systems so that they don’t have to understand the technical particulars of the system they are calling. A Java – based system making a call into a service on a Windows server would do so through the use of a middleware server, which handles the translation between platforms in a manner that isolated one from the other. However, disparate operating systems weren’t the only impediment that made interoperability so difficult. Varying architectures had a similar need for middleware. A system that used a web model for housing application logic would often need to invoke the services of a client application on a limited number of distributed machines. Likewise, client applications often had the need to call into an application server as a web request, even though no implicit web communication model was built into the software. The complexities of interoperability increased dramatically as systems began to depend on isolated servers for broad, comprehensive tasks, such as authentication and authorization. Authentication servers built on the Lightweight Directory Access Protocol, or LDAP model, became the standard for network security calls. As more systems began to rely on services from other systems, they also required iterative calls into LDAP servers. Taking this model a step further, increased data needs also lead to increased interoperability demands. Consuming applications in need of data from multiple systems began connecting to different relational database management systems at runtime. Each database had its own security roles and levels of authorization, requiring even more calls into security LDAP servers. Now, even a simple task might require communication between three, four, or even five different systems, each one using its own architecture and technical platforms.

Enterprise middleware evolved with the industry’s communication needs. Early middleware models were somewhat rudimentary. Organizations in need of complex interoperability often attempted to design their own middleware, complete with a set of messages and protocols that were entirely of their own devising. Simple text - based patterns such as string delimiters were used in flat file exchanges to transmit data from one machine to another. The limitations of this approach were almost immediately apparent. As organizations attempted to share system services with other organizations, a considerable amount of work was required to translate the nonstandard message patterns. Even when the translation was in place, maintaining and updating these patterns was a cumbersome task.
The task of translation was moderately simplified with the emergence of Extensible Markup Language, or XML, as the primary means of message exchange. XML provided a language pattern for conveying message - based concepts common to all systems. XML ’ s rich format allowed for the defining of data structure, especially pertaining to parent - child relationships inherent to data hierarchies. XML also provided a means for the defining of basic data types, such as integers, strings, and double – precision floats. XML documents such as the Document Type Definition (DTD) and XML Schema (XSD) quickly became the industry standard for defining types and applying simple validation to the fields each type supported. All of these patterns eased the pain of defining the system - to - system messages, but designers still needed to come up with their own message structures to match the requisite invocation signatures of the target services. There was no standard methodology for these messages, and there were no mechanisms in place to provide a well - known model to act as a roadmap for new consumers.

The emergence of web services helped to lower the interoperability curve. Web services were one of the first widely embraced machine - to - machine interactions over a network using non - platform – specific conveyances. They provide an open means of invoking methods on another system, most commonly known as a remote procedure call, or RPC. RPC models have been around for quite some time, with support from varying invocation frameworks such as XML - RPC, the Common Object Request Broker Architecture (CORBA), the Distributed Component Object Model (DCOM) and the Java platform’s Remote Method Invocation (RMI) framework. RPC models can be either synchronous or asynchronous. However, the former has proven to be a more commonly embraced model than the latter. Web services provide a framework for synchronous remote procedure calls over a network and are a useful layer within an enterprise middleware system.

The architecture of a web service can be fairly complex; a full description of web service architecture lies outside of the scope of this book. However, some of the core principles behind them are important keys to understanding enterprise middleware as it has evolved. A true web service exposes a public endpoint often referred to as a web method. A web method uses basic HTTP communication standards for sending text - based data across a network in a format known as Simple Object Access Protocol, or SOAP.
SOAP messages are written using XML, and expose two key elements: the envelope and the message body. The envelope contains critical metadata about the message being passed, while the body contained the data to be delivered to the service. Web services were also required to publish a service descriptor file, using a pattern known as Web Services Description Language, or WSDL. A WSDL file was served out with the public method, providing up - to - date information and instructions for calling the web method. To discover web services, various service broker models began to pop up, delivering a sort of online yellow pages for available web services. Overall, however, the SOAP model has remained consistent enough to provide organizations with a stable model for requesting and responding to networked service calls.
Web services helped the software industry realize a level of predictability otherwise unseen in the enterprise community. Since the web service model was both transparent and pervasive, tools began to surface to eliminate the need for developers to understand the service architecture itself. Since the XML was standardized, each development platform could implement features and utilities to automatically create the XML messages and corresponding files on the fly, without forcing the programmer to write a lot of markup to expose their methods.
Web services on the Windows platform have evolved along with some of the latest web services trends. With the initial release of ASP.NET in the .NET 1.0 Framework (2002) Microsoft provided a mechanism for defining and consuming web services on top of the ASP.NET model with relative ease. Readers with experience using ASP.NET are likely familiar with .asmx files. The .NET SDK came complete with a set of command - line utilities for interrogating online web services using the web standard published by the W3C. These utilities could be used to define web methods in an ASP.NET project, and expose them as public web services in a file known as an .asmx file. These files translated the web method requests and responses into SOAP - based messages and exposed a WSDL file for other downstream consumers. These same utilities could also be used by calling .NET clients to read the published WSDL file and generate a local proxy class through which web methods could be invoked. The generated proxy classes would translate incoming and outgoing messages to and from XML SOAP, eliminating the need for the consuming developer to write any XML messages.

ASP.NET web services were popular for small application data exchange but fell short of delivering an enterprise model for system - to - system interoperability. The tools provided were Microsoft - specific. While they worked well for communicating between Windows applications, there were various technical nuances that made communicating with a non - Windows platform difficult to accomplish. The SOAP messages used were not entirely standardized, leaving developers at a loss when choosing the right SOAP version for their calls. Moreover, the communication model was irregular. The .asmx web service model was built directly on top of the ASP.NET framework, coupling the web service model with the ASP.NET event lifecycle. This added runtime overhead and made maintenance efforts harder. Since then, Microsoft has released the Windows Communication Foundation, or WCF framework. WCF is a framework and API dedicated to all manner of machine - to - machine communication. Like Java and other popular development platforms, WCF aims to unify the communication stack for all Microsoft systems.
This new communication model is far better suited for growing systems with changing communication needs and is ideal for building true enterprise middleware.

More about Enterprise application will be introduced, specially concerning interoperability...
Stay Tuned

Integrating WCF with WF

2011-05-03T00:23:00.004+03:00

Workflows are presented in software development as an effective tool for solving problems or accomplishing business goals. By splitting them into smaller and more manageable pieces, they can be coordinated into a single process. Workflows also bring reusability and maintainability — two core quality principles in software engineering. They are promoted by workflows because they have smaller pieces that can be reused across several processes and are easier to maintain. These pieces or reusable assets receive the name of activities, and usually describe the work performed by the people or software involved in the process. When designing workflows within an enterprise application using a bottom - up approach, they are first designed as a set of primitive activities to control the execution flow, communicate with the outside world, or execute actions to change the workflow’s internal state. These workflows can later be converted to activities and used as a compositional unit for creating other workflows that coordinate work at a higher level. In this way, the design process can be applied recursively to a number of abstraction levels that we might find necessary.
The same design paradigm can be applied in the service - oriented world. A service can be implemented througha combination of primitive activities in a workflow, or a service can be the result of a workflow that orchestrates other services to accomplish a business goal.
For instance, a service for submitting a new order in a supply management application might require the coordination of other services to verify or update the stock level of the ordered product. All the work needed to coordinate these service calls can be modeled through a simple workflow. However, implementing a service as a workflow is not as simple as it sounds. There are challenges that need to be addressed, and without the help of the right technology, they would be almost impossible to achieve: A long - running process that interacts with people might take hours or days to complete. For instance, a service that implements a document approval workflow. For this kind of service, a mechanism is needed to save the workflow state across different service calls. We can’t keep the state in memory forever, as it is volatile storage and a performance bottleneck when the number of running workflows gets high. Multiple messages that represent business events might come in or go out from a given service instance. A mechanism to correlate all these messages into the same service instance is required to resume the workflow execution in the correct step and with the correct state.
Workflow Foundation (WF) is the technology that helps we in this area. Fortunately with the introduction of new activities to build workflow - enabled or workflow services, it has been closely integrated with WCF in the .NET Framework 3.5. WCF in that sense provides the necessary infrastructure to communicate the workflows with the external world through incoming and outgoing messages.
Throughout the below, we will see this relationship has been improved in version 4.0 with the introduction of new features such as content correlation, declarative services, and the new runtime model and activity library.

ANATOMY OF A WORKFLOW SERVICE

A workflow service created with WF maintains state, gets input messages from and sends output messages to the outside world, and executes code that performs the service ’ s work. This is the same as an ordinary stateful service, which preserves a shared state between different operations during its lifetime.
Every workflow service has an outermost activity, the workflow itself, which contains all other activities. This outer activity can take different shapes, and basically determines the way the execution flow goes through different inner activities. WF 4.0 ships with two built - in activities for modeling workflows: a sequence activity that flows from one activity to the next until the last activity is executed, and a flowchart activity that resembles the concepts that many analysts and application designers go through when creating solutions or designing business processes.

we should also understand that the WF runtime does not know anything about the internal implementation of the activities it is executing, or the way it behaves. It can only run one activity after another, until the last activity is reached. It can also persist the workflow state at certain points. Now, we might wonder why we should go with a workflow service when the same service can be implemented manually with code? The answer is, to address some of the benefits that WF can give in this area:
The automatic support for long - running workflows that the WF infrastructure provides is the most evident benefit. The execution of a long - running workflow can be suspended or resumed on multiple points, so the internal state of the execution and activities must be preserved. WF automatically takes cares of saving the workflow state through the use of configurable providers. Therefore, we do not need to worry about these details.
The implementation of a complex service that orchestrates several other services with a certain degree of parallelism gets simplified with the use of a workflow. All the aspects related to message correlation are automatically handled by the WF infrastructure. The same implementation made purely on code would require a lot of plumbing code and some knowledge about concurrent programming. This is necessary to be efficient when coordinating all the service calls and correlating all the responses in the same way WF would do it.
A service might need to execute some kind of compensation logic or be suspended when an unexpected situation or exception occurs during its execution. For instance, a service that depends on other services to perform an action might not be able to complete its execution when any of these are not available, which might lead to some data inconsistencies. If we use a workflow to implement this service, the workflow itself can be suspended and restarted later when the dependent services are available.
The declarative model and visual designer that WF provides becomes handy at the moment of building simple services without worrying about implementation details of the WCF ABC (Address, Binding, and Contract). We can focus on a declarative model that simply creates variables that are handled in the workflow, and activities that initialize these variables and change their values, sending them to the outside world.

DECLARATIVE SERVICES

One of the main problems of implementing workflow services in the .NET Framework 3.5 is that the integration between these technologies leaves something to be desired. We basically have to define all the WCF artifacts using the WCF programming and configuration model, and the workflow using a different model, resulting in a set of multiple artifacts that need to be deployed and managed separately.
However, with the .NET Framework 4.0, we can define all the WCF artifacts, such as contracts and operations, using XAML (eXtensible Application Markup Language) together with the workflow definition in the same language, resulting in a single artifact — a XAML - based service. In other words, we essentially create a model of the service defining what the service should do, rather than writing code to specify how to do it — the traditional way to do things in .NET.
Below is the XAML representation of a workflow service with a simple operation, GetData , that receives an input argument in the variable "data" and returns a string ( data.ToString() ). As we can see, all the activities have been represented as objects with properties using the XAML notation.

< WorkflowService ConfigurationName="Service1" Name="Service1" .... >
< p:Sequence DisplayName="Sequential Service" >
< p:Sequence.Variables >
< p:Variable x:TypeArguments="CorrelationHandle" Name="handle" / >
< p:Variable x:TypeArguments="x:Int32" Name="data" / >
< /p:Sequence.Variables >
< Receive x:Name="__ReferenceID0" DisplayName="ReceiveRequest"
OperationName="GetData" ServiceContractName="contract:IService" >
< Receive.CorrelationInitializers >
< RequestReplyCorrelationInitializer CorrelationHandle="[handle]" / >
< /Receive.CorrelationInitializers >
< ReceiveMessageContent >
< p:OutArgument x:TypeArguments="x:Int32" > [data] < /p:OutArgument >
< /ReceiveMessageContent >
< /Receive >
< SendReply Request="{x:Reference Name=__ReferenceID0}"
DisplayName="SendResponse" >
< SendMessageContent >
< p:InArgument x:TypeArguments="x:String" > [data.ToString()] < /p:InArgument >
< /SendMessageContent >
< /SendReply >
< /p:Sequence >
< /WorkflowService >

In addition, the contract and operations for this service are automatically inferred from the Receive Activity definition. A great advantage of having a fully declarative service is that we can store the complete definition in a service repository and take full control of the workflow’s instances from a hosting environment such as Windows AppFabric.

IMPLEMENTING OUR FIRST WORKFLOW SERVICE

We have seen some introductory theories behind workflow services and the messaging activities that can be used in this kind of service to receive messages or invoke external services. It is now time to jump into a more concrete example to see a workflow service in action. This example represents the implementation of a service for entering purchase orders into a system. For practical purposes, this service will also invoke an external service for every received order. Let’s start creating a C# class library for including the definition of the contract and implementation of the external service invoked within the workflow service. The implementation is simple enough: it receives the product that was ordered, the quantity associated to the order, and returns a Boolean value specifying the success of the operation. See below

[ServiceContract]
public interface IProductNotification
{
[OperationContract]
bool Notify(string product, int quantity);
}
public class ProductNotification : IProductNotification
{
public bool Notify(string product, int quantity)
{
return true;
}
}

Now that we have the external service implementation, we can focus on the implementation of the first workflow service. Visual Studio 2010 provides a template WCF Workflow Service Application under the Workflow category, which we can use to create workflow services from scratch. When that template is selected and executed, a new web project is generated with a sample workflow service definition that includes a pair of Receive/Send Activities. Start the implementation of your workflow service by removing those activities.
This service will initially receive a purchase order as it is defined in the PurchaseOrder data contract check below through a new Receive Activity that we need to create in the workflow. This activity basically represents the initial entry point for the service.

[DataContract]
public class PurchaseOrder
{
[DataMember]
public string Customer { get; set; }
[DataMember]
public string Product { get; set; }
[DataMember]
public int Quantity { get; set; }
[DataMember]
public decimal UnitPrice { get; set; }
}

We should set the Receive Activity properties with the values specified below

PROPERTY                    VALUE
DisplayName                 SubmitPOReceive
OperationName               SubmitPO
ServiceContractName         IPurchaseOrder
CanCreateInstance           True
Content                     PurchaseOrder

Leave the rest of the properties with the default values. The designer will complain that the PurchaseOrder variable is not defined, and that is exactly what we do next. The variables can be defined for a workflow instance in the Variables tab, which usually appears at the bottom margin of the designer. A variable definition is made of three parts: a name, a type, and a scope. The variables, as in any language, are referenced by name, and the type is any valid CLR type shipped as part of the framework or a type created for us. In this case, we define a variable called PurchaseOrder whose type is PurchaseOrder (a data contract defined in another project) and is scoped to the current workflow service (Sequential workflow service). As we can see, we have a single data contract parameter to receive all the information, so Message Data is just fine for that purpose. In case we want to support multiple arguments in the operation signature, we need to use parameters and assign them to the corresponding variables or use VB expressions to do more complex assignments.
The workflow is now ready to start receiving messages containing the purchase order information through the operation SubmitPO . As we haven’t defined a SendReply Activity, this operation momentarily behaves as one - way. The next step is to invoke the ProductNotification service for every receive order. The easy way to include that service call in the existing workflow is to use the automatic generated activity. The only thing to do is add a service reference for ProductNotification When the reference is added to the project, we should be able to see a new activity called Notify with a public interface that resembles the Notify operation in the IProductNotify contract. It has two public properties for setting the product and quantity respectively, and a third property for getting access to the operation return value. We can drag and drop that activity after the Receive Activity and fill out the properties with the values in the below list

PROPERTY               VALUE
NotifyResult           NotifyResult
Product                PurchaseOrder.Product
Quantity               PurchaseOrder.Quantity

NotifyResult is a new Boolean variable that needs to be defined to receive the result of the operation. The Product and Quantity input arguments are initialized from the existing variable PurchaseOrder by using expressions.

Last but not least, we need to create a new SendReply Activity from the SubmitPOReceive Receive Activity to send the results back to the client. The only thing needed is to set up this activity in the Content property to use Message data and True as value, so it will basically return a value indicating the operation was executed successfully.
At this point, the workflow service is ready to use, and any client can access the service WSDL by browsing the POService.xamlx file directly in the corresponding web host (IIS virtual directory or Visual Studio web server). This means that the service behaves as any other WCF service from the point of view of a client application, and a tool such as svcutil can be used to generate the proxy classes to consume it.

PurchaseOrderClient client = new PurchaseOrderClient();
bool? result = client.SubmitPO(new ServiceReference.PurchaseOrder
{
Customer = "John BarFoo",
Product = "myproduct",
Quantity = 10,
UnitPrice = 1
});
Console.WriteLine(result.GetValueOrDefault());

Hope this small demonstration has opened a gate to this approach, stay tuned more examples to come.

The .NET Platform

2011-05-01T13:34:00.001+03:00

The .NET platform is Microsoft’s development platform for Windows and the cloud. This includes support for desktop applications, smart device applications, server and database applications, web applications and services, and cloud applications deployed to Windows Azure.
In addition, the technology is available in more exotic corners of computer science, ranging from operating system implementation (for example, Microsoft Research’s Singularity research operating system) to gaming with the XNA framework and Microsoft Robotics Studio for robotics. Figure below gives an overview of the .NET platform

Let’s point out the key features and advantages of the .NET platform as a whole:

Object-oriented programming: Recognized to be the current paradigm of choice to master complexity, the platform was built around the concepts of object-oriented programming (OO). The core of languages like C# are based on the OO principles, and the OO paradigm is used as the glue that makes language interoperability possible.

Support for multiple languages: Although COM supported multiple languages (most notably C++ and Visual Basic) in order to talk together, its cross-language capabilities were limited to implementing interfaces. In .NET, true interoperability between languages becomes possible with capabilities such as cross-language inheritance. Together with a unified type system, this makes integration between code written in different languages totally seamless. This also accommodates other programming language paradigms, ranging from a functional programming style (as seen in F#, but nowadays in certain C# and Visual Basic language features too) to dynamic languages (such as Ruby and Python).

Easy component-based development: The art of creating components containing libraries and sharable pieces of application functionality is much simpler in .NET than it was before. No COM interfaces like IUnknown need to be implemented, and no registration is required. The unit of code sharing in .NET is based on the concept of an assembly, which carries version info and all the metadata required to use it. This eliminates the need to have separate header files and such.

Simplified application deployment: In contrast to COM-based components, no registration is required to deploy assemblies; just “xcopy deployment” suffices. In addition to this, the DLL hell has been eliminated by supporting multiple versions of the same component to exist side by side. The .NET Framework itself is a good example of this capability, because it’s possible to have multiple versions of the framework installed next to one another on the same machine.

Rich base class library support: The .NET Framework comes with a rich set of class libraries that provide basic building blocks to build rich applications, all of which are provided in a consistent manner and designed based on OO principles. Examples of such libraries include collections, text manipulation, database access, file system manipulation, networking, XML support, rich service-oriented communication stacks, windowing systems, and so on.

Various application types: Thanks to the rich base class library (BCL), it becomes incredibly easy to write all sorts of applications based on the same framework foundation. Support is provided for Windows desktop GUI applications (Windows Forms
and Windows Presentation Foundation [WPF]), web applications (ASP.NET), web services (Windows Communication Foundation [WCF]), smart device applications
(Compact Framework), browser and Windows Phone 7 applications (Silverlight), cloud applications for Windows Azure, and more.

Unified runtime infrastructure: At the core of the .NET Framework sits the Common Language Runtime (CLR), which provides unified runtime infrastructure in the form of an intermediate language (IL) shared by all languages that run on the platform, Just-in-Time (JIT) compilation of such IL code to native code for the machine on which it’s running, automatic memory management through a garbage collector (GC), assembly loading services, debugging services, threading, and so on.

Interoperability with existing code: Although the .NET platform is meant to be a solid replacement for older technologies, it’s quintessential to have good support to reuse existing software components that were written in older technologies like COM and to provide access to native operating system Win32 API functions through a mechanism called P/Invoke.

Exception handling: Error handling in the .NET Framework is provided through a mechanism known as exception handling. This eliminates many of the worries associated with manual error checking as done in Win32 programming and COM-based
APIs with so-called HRESULTs.

Improved security model: With the advent of the Web, deployment of code becomes a severe security risk. To mitigate this, the .NET runtime has a built-in security mechanism called Code Access Security (CAS) that sandboxes code based on the code’s origin, publisher evidence, and configurable policies. This security model is orthogonal to the security mechanisms provided by the operating system, such as access control lists (ACLs) and Windows security tokens.

Web services capabilities: Right from the start of the .NET Framework, the platform has had support for web services as a modern way of performing cross-platform remote procedure calls based on Simple Object Access Protocol (SOAP) and Extensible Markup Language (XML) standards. All this is provided using programming paradigms that feel natural in the world of .NET, so developers do not require a fundamentally different mindset to deal with web services. Over the years, the web services support on the .NET Framework has grown significantly with support for the WS-* set of web services standards.

Professional tooling support: Visual Studio 2010 is the latest version of the toolset that accompanies the .NET Framework to provide professional support for the development of various types of applications with rich designer support, unit testing frameworks, a project and build system (MSBuild), and, thanks to the unified runtime infrastructure, rich debugging support can be provided for the cross-language platform of .NET. The higher-end editions of Visual Studio, Premium and Ultimate, are aimed at team development in conjunction with a server product called Team Foundation Server (TFS) used for work-item tracking, source-control, project-reporting, and document-sharing capabilities. Starting with the 2010 release, you can also install TFS on client operating systems, which allows individual professional developers to benefit from things such as source control.

Stay tuned

Application Middleware Design

2011-04-16T13:00:00.001+03:00

Business Logic Layer

The business logic layer is an abstract layer that contains all the rules, workflow and validation that define and deal with the business complexities that your software has been designed to meet. Typically, the business logic layer will fit between your user interface, service, or presentation layer and your data access layer. By separating the business logic from other layers in your applications you are separating your concerns and keeping your code loosely coupled and allowing for different implementations to be used with the business logic layer; for example, changing the UI from a web application to a WPF application.

WPF Win Forms --- Web Forms --- Other Services
-------------------------------------------------------------------
Service Layer
-------------------------------------------------------------------
Business Logic Layer
-------------------------------------------------------------------
Data Access Layer
-------------------------------------------------------------------
Data Sources

Depending on the complexities of the business model that your application has been designed for, the structure of your business logic layer may differ considerably. For instance a complex banking application will have a rich Domain Model that represents the real banking domain with hundreds of small business entities representing loans, customers, and accounts. For a simpler application, such as a blogging engine, you may have a number of fairly simple business objects that map very closely to your underlying Data Model with little or no business logic, simply acting as a method to add and retrieve data. In the next section, you will look at the various patterns at your disposal to structure your business logic layer.

Patterns for Your Business

There are a number of design patterns that you can follow that will help you to organize your business logic. In the below part, you will be introduced to three of the main patterns found in the business logic layer: the Transaction Script, Active Record, and the Domain Model pattern.

Transaction Script

Transaction Script is a very simple business design pattern, which follows a procedural style of development rather than an object - oriented approach. Simply create a single procedure for each of your business transactions with each procedure containing all of the business logic that is required to complete the business transaction from the workflow, business rules, and validation checks to persistence in the database.
One of the strengths of the Transaction Script pattern is that it is very simple to understand and clear to see what is going on without any prior knowledge of the pattern. If a new business case needs to be handled, it is straightforward enough to add a new method to handle it, which will contain all of the related business logic.

The problems with the Transaction Script pattern are revealed when an application grows and the business complexities increase. It is very easy to see many management or application classes with hundreds of fine - grained transaction methods that map directly to a business use cases. Sub methods can be used to avoid repetitive code such as the validation and business rules, but duplication in the workflow cannot be avoided, and the code base can quickly become unwieldy and unmanageable as the application grows.

If you have a simple application with minimal business logic, which doesn’t warrant a fully object - oriented approach, the Transaction Script pattern can be a good fit. However, if your application will grow, you may need to rethink your business logic structure and look to a more scalable pattern like the Active Record pattern.

Active Record Pattern

The Active Record pattern is very popular pattern and is especially effective when your underlying database model matches your business model. Typically, a business object will exist for each table in your database.
The Active Record pattern is great for very simple applications where there is a one-to-one mapping between the Data Model and the Business Model, such as with a blogging or a forum engine; it ’ s also a good pattern to use if you have an existing database model or tend to build applications with a “ data first ” approach. Because the business objects have a one - to - one mapping to the tables in the database and all have the same CRUD (create, read, update, and delete) methods, it ’ s possible to use code generation tools to auto - generate your business model for you. Good code gen tools will also build in all of the database validation logic to ensure that you are allowing only valid data to be persisted.

However, the Active Record pattern is no silver bullet. It excels with a good underlying Data Model that maps to the business model, but when there is a mismatch, sometimes called an impedance mismatch, the pattern can struggle to cope. This is the result of complex systems sometimes having a very different conceptual business models than the Data Model. When there is a rich business domain with lots of complex rules, logic, and workflow, this favors going with the Domain Model approach.

Domain Model Pattern

You can think of a Domain Model as a conceptual layer that represents the domain you are working in. Things exist in this model and have relationships to other things. What do I mean by things? Well, for example, if you were building an e - commerce store, the “things” that would live in the model would represent a Basket, Order, and Order Item, and the like. If you were creating a loan application, you would have representations for a Borrower, Loan, Assets, and Debts. It’s these things that have data and, more importantly, behavior. Not only would an order have properties that represent a creation date, status, and order number, but it would also contain the business logic to apply a voucher to, including all of the domain rules that surround it — Is the voucher valid? Can the voucher be used with the products in the basket? Are there any other offers in place that would render the voucher invalid, and so forth. The closer your Domain Model represents the real domain the better, as it will be easier for you to understand and replicate the complex business logic, rules, and validation process.

The main difference between the Domain Model and the Active Record pattern is that the business entities that live in the Domain Model have no knowledge of how to persist themselves, and there doesn’t necessarily need to be one - to - one mapping between the Data Model and the Business Model.

As mentioned earlier, the Domain Model, unlike the Active Record pattern, has no knowledge of persistence. The term persistence ignorant (PI) has been coined for the plain nature of the POCO(plain old common runtime object) business entities. How then do you persist a business object with the Domain Model?

Typically, the repository pattern is used. When you are employing the Domain Model pattern, it’s the responsibility of the Repository object, along with a data mapper, to map a business entity and its object graph of associated entities to the Data Model. Be aware that business entities inside the Domain Model are PI.

Trying to solve complex business problems in software is difficult, but when using the Domain Model pattern, you first create an abstract model of the real business model. With this model in place, you can then model complex logic by following the real domain and recreating the workflow and processing in your Domain Model. Another advantage that a Domain Model holds over the Transaction Script and the Active Record patterns is that, because it contains no data access code, it can be easily unit tested without having to mock and stub out dependencies of such a data access layer.

Again, the Domain Model pattern may not always be a great fit for your application needs. One of its great strengths is dealing with complex business logic, but a full - blown Domain Model is architectural overkill when very little business logic is contained within the application. Another disadvantage of the pattern is the steep learning curve needed to become proficient in it compared to the Active Record and Transaction Script options. To use the pattern effectively takes time and experience and, most importantly, a sound knowledge of the business domain you are trying to model.

Which Pattern to Use?

Each pattern has its pros and cons, and there is no one method that will suit all of your development needs. Let’s take a brief look at each pattern and see when it’s most appropriate to use it.

Transaction Script: If you have a simple application with little or no logic, then Transaction Script is a great choice as a straightforward solution that is easily understood by other developers picking up your code down the line.

Active Record: If your business layer is simply a thin veil over the top of your database, then this is a great pattern to opt for. There are many code generation tools that can automatically create your business objects for you based on your database schema, and it ’ s not too difficult to create your own.

Domain Model: The Domain Model excels when you have an involved, rich complex business domain to model. It’s a pure object - oriented approach that involves creating an abstract model of the real business domain and is very useful when dealing with complex logic and workflow.
The Domain Model is persistence ignorant and relies on mapper classes and the Repository pattern to persist and retrieve business entities.

It now your decision how to implement your application’s Middleware. But keep in mind that a good design will calculate the support time and application extensibility.

Stay tuned for more, and share it with your Development cycle.

Business Intelligence

2011-04-12T00:36:00.002+03:00

Business intelligence (BI) refers to computer-based techniques used in identifying, extracting, and analyzing business data, such as sales revenue by products and/or departments, or by associated costs and incomes.
BI technologies provide historical, current and predictive views of business operations. Common functions of business intelligence technologies are reporting, online analytical processing, analytics, data mining, business performance management, benchmarking, and text mining and predictive analytics.
Business intelligence aims to support better business decision-making. Thus a BI system can be called a decision support system (DSS).Though the term business intelligence is sometimes used as a synonym for competitive intelligence, because they both support decision making, BI uses technologies, processes, and applications to analyze mostly internal, structured data and business processes while competitive intelligence gathers, analyzes and disseminates information with a topical focus on company competitors. Business intelligence understood broadly can includethe subset of competitive intelligence (previous definition from Wikipedia)

Business Challenges:

-Data is stored in a number of different systems on different platforms, such as inventory and logistics in SAP, financials in Oracle, web analytics in SQL Server, and manufacturing on the mainframe. This can make data difficult to get to, require multiple accounts for access, and keep teams and departments at arm’s length from each other.

-Pockets of knowledge about the data are spread throughout teams that don’t regularly interact. This spread causes data to be analyzed in different ways and metrics to be calculated inconsistently, which, in turn, leads to unpredictable analysis and inappropriate actions being taken based on the data.

-Documentation is limited or nonexistent. Many times documentation is not created for reports or the metadata underneath them, and this lack of documentation is a critical problem. If you don’t know where the data is coming from for the report, or how certain metrics are being calculated, then you can’t truly understand or communicate the value of the data and calculations.

-Consolidated reporting is very time-consuming, when it is possible at all. With reports coming from so many different places, you run into the same problems mentioned in the previous point. These challenges require more people to know different reporting systems, lead to more administrative headaches, and so on.

-Reporting teams spend significant time finding and aligning data instead of analyzing and mining it for actionable information. If reporting teams need to go out and gather data from across the company constantly, this doesn’t leave much time for analyzing and interpreting the data. These challenges cause many reporting teams to rework large portions of their reports several times as opposed to spending that time understanding what the users are asking for and delivering more actionable information.

How Intelligent Is Your Organization?

Business Intelligence (BI) is a term that encompasses the process of getting your data out of the disparate systems and into a unified model, so you can use the tools in the Microsoft BI stack to analyze, report, and mine the data. Once you organize your company’s data properly, you can begin to find information that will help you make actionable reports and decisions based on how the data from across your organization lines up. For instance, you can answer questions like, “How do delays in my manufacturing or distribution affect my sales and customer confidence?” Answers like this come from aligning logistics data with sales and marketing data, which, without a Business Intelligence solution, would require you to spend time exporting data from several systems and combining it into some form that you could consume with Excel, or another reporting tool.

Business Intelligence systems take this repetitive activity out of your life. BI automates the extracting, transforming, and loading (ETL) process and puts the data in a dimensional model that sets you up to be able to use cutting-edge techniques and everyday tools like Microsoft Excel to analyze, report on, and deliver results from your data.

Getting Intelligence from Data

How do you get information from data? First, you need to understand the difference. As you learned earlier, data can come from many different places, but information requires context and provides the basis for action and decision-making. Identifying your data, transforming it, and using the tools and techniques you learn will enable you to provide actionable information out of the mass of data your organization stores. There are several ways to transform your data into actionable information and each has its pros and cons.
Typical solutions for reporting include a few different architectures:

Departmental reporting: Many organizations have their own departmental reporting environments. This situation leads to a significant increase in licensing costs, since using different vendors for each department and reporting environment increases spending on hardware and software licensing, end-user training, and ramp-up time.

Individual data access: Some organizations find it easier to grant lots of individual user’s access to the data. This is not only dangerous from a security perspective, but likely to lead to performance problems, because users are not the most adept at creating their own queries in code. Also, with all the industry and federal compliance and regulation governing data access, widespread access can quickly lead to a security audit failure, especially in a publicly held company.

BI add-on from each vendor: When teams seek out and apply different strategies, it exacerbates the original problem of data being all over the organization. The data will still be segmented, and additionally the analysis on it will be inconsistent and applied based on each team’s individual understanding of how its data fits into the enterprise, instead of the correct view based on the organizational goals.

Automated reports from different systems: It may be nice to get the automated reports and they likely serve a purpose, but they usually cannot be counted on to run an enterprise.
Strategic reporting, dashboard drill-through, and detailed analysis require a BI implementation to support them and provide the “at your fingertips” data and analysis that your end users, managers, and executives are craving.

You have likely seen some form of all of these problems in your organization. These are the opposite of what you want to accomplish with a great BI infrastructure.

BI to the Rescue

A well-thought-out BI strategy will mitigate the problems inherent to each of the previously listed approaches. A good BI approach should provide the targeted departmental reporting that is required by those end users while adjusting the data so it can be consumed by executives through a consolidated set of reports, ad hoc analysis using Excel, or a SharePoint dashboard. Business Intelligence provides a combination of automated reporting, dashboard capabilities, and ad hoc capabilities that will propel your organization forward.

BI provides a single source of truth that can make meetings and discussions immediately more productive.
How many times have you gotten a spreadsheet via e‑mail before a meeting and shown up to find that everyone had his or her own version of the spreadsheet with different numbers? Business Intelligence standardizes organizational calculations, while still giving you the flexibility to add your own and enhance the company standard. These capabilities allow everyone to speak the same language when it comes to company metrics and to the way the data should be measured across the enterprise or department.
Integrating Business Intelligence with your organization’s current reporting strategy will improve the quality of the data as well as the accuracy of the analysis and the speed at which you can perform it. Using a combination of a data warehouse and BI analytics from Analysis Services and Excel, you can also perform in-depth data mining against your data. This enables you to utilize forecasting, data-cluster analysis, fraud detection, and other great approaches to analyze and forecast actions. Data mining is incredibly useful for things like analyzing sales trends, detecting credit fraud, and filling in empty values based on historical analysis. This powerful capability is delivered right through Excel, using Analysis Services for the back-end modeling and mining engine.

BI = Business Investment

A focused Business Intelligence plan can streamline the costs of reporting and business analytics. The Microsoft BI stack does a great job of providing you with the entire tool set for success within SQL Server Enterprise Edition. We provide more details on that shortly, but the most important bit of information you should take away right now is that the cost of managing multiple products and versions of reporting solutions to meet departmental needs is always higher than the cost of a cohesive strategy that employs one effective licensing policy from a single vendor. When organizations cannot agree or get together on their data strategy, you need to bring them together for the good of the organization. In the authors’ experience, this single, cohesive approach to reporting is often a gateway to a successful BI implementation. Realizing the 360-degree value of that approach and seeing the value it can have in your organization are the two most important first steps.

Microsoft’s Business Intelligence Stack

Microsoft’s Business Intelligence stack comes with SQL Server and is greatly enhanced with the addition of SharePoint Server.
We will discuss the SQL Server Integration Services (SSIS) in upcoming articles, mean while you have the topic and you can do research more and deep about it. Stay tuned…

The Enterprise Application Concepts

2011-04-07T09:31:00.003+03:00

Most people who begin learning enterprise development find that the best place to begin is the code. Readers should be familiar with a third generation object - oriented (OO) language to fully grasp some of the concepts discussed here.
After reading this article hopefully, you’ll become familiar with some pretty slick tools, some of which produce some pretty fancy behaviors. Yet these tools are each meant as a complement to a well - designed code base. Without good code design, these tools are rendered useless; many will fail to function at all. The reason for this failure is that a well – designed enterprise system should be constructed using code that adheres to one of the core values of enterprise design: separation of concerns. To achieve the correct degree of separation, developers should strive to write their code with a strong degree of modularity and loose coupling.

Modularity

The notion of code separation is one of the single most important facets of enterprise development.
Traditional Microsoft developers have at their fingertips a wide array of powerful RAD tools that empower them to quickly automate macros and execute applications. Unfortunately, these tools don’t enforce a strong degree of modularity. Althoughthe code produces a desired result, the result is limited and not entirely reusable. Well - designed code must be broken down and divided into separate “vehicles of purpose.” In the enterprise world, these are known as units of codes.
Units of code are typically classes or types designed with a specific purpose in mind. The purpose should be well focused, striving to achieve the single desired goal for which the type was initially designed. As various units of code are developed, they can be designed to interact with one another in a manner that achieves a larger desired effect without violating the rules that drive their division.
We know that this sounds pretty confusing at first, but take heart — most seasoned Microsoft developers still have a tough time thinking in terms of true separation. When it comes to developing business applications the vast majority of us are wired to think of the desired outcome and then work backward.
Think about most of the business requirements for which you’ve developed code. A manager or project leader gives you the task of building a thing that does X. You then work backward from X, constructing the code line by line in your mind until you have a rough roadmap for a prototype. You then translate this roadmap into whatever code gets the desired outcome the quickest in order to produce the results for the tasking manager. Yet this process skips the critical step of assessing code design before you write the code. The result is a pile of spaghetti code that isn’t reusable and, moreover, isn’t testable.
In cases such as these, it is critical for the developer to assess the design early, and understand the individual elements that will be needed to make the system function.
Consider a requirement where you are tasked with creating a small client application that creates automated email newsletters advertising discounted auto parts. You ’ re given a list of discounting rules based on the location where a user lives, and a small desktop database containing the list of automotive parts and their prices. Another database is given to you containing a list of user emails and the geographic location from which each user hails. Finally, you’re provided with a brief list of preferred styles for HTML - compliant email clients. Generally speaking, an application like this is a no brainer. Most developers experienced with Microsoft Office automation or simple ET.NET forms programming could create a console application that gets the job done in a handful of function calls. Yet the resulting code is unorganized. It combines UI styles, database calls, and business rules into one convoluted stack of code.
Most developers have experimented with some modularity in the past. You might have moved recursive calls into a separate function, maybe created a class or two for accessing data, or perhaps you’ve dabbled with some object - oriented design patterns, like a Factory model or Decorator pattern. Wouldn’t these deliver an acceptable amount of modularity? Not necessarily. Patterns such as these do provide a useful means of separation; however, when developing enterprise systems modularity isn’t just about separation of your code for reusability. Enterprise development typically requires a strong degree of loose coupling.

Loosely Coupled Classes

Loose coupling is a pattern that embraces a high degree of entity separation. It describes a resilient relationship between two or more objects or systems where information can be exchanged or invoked with minimal dependency on one another. The term dependency can be used to describe a number of different aspects of reliance between two things, some of which may be more valid than others. In the case of enterprise development, a dependency is typically used to describe a runtime need for one class by another. The goal of loose coupling is to minimize these runtime links.
When it comes to enterprise development, loose coupling may be one of the strangest shifts you’ll make when coding. Up until now you’ve likely been quite comfortable with a very traditional flavor of object - oriented programming. You define classes that perform various tasks, and provision them with attributes accordingly. The class might need some form of initialization so that you code a constructor that creates new objects, connects to different services, and populates properties accordingly. This approach is fine for small systems, but it ’ s far from ideal for a large system that interacts with multiple services and consumers. The problem with this approach is that it prevents the creation of autonomous units. Recall that a unit of code is a class or entity designed to perform a single task. If a unit of code requires the consuming of services from other parts of the system, these services should be passed into the unit abstractly. It should never be the job of a unit to create the dependencies it needs. Right about now you’re likely sporting a tightly furrowed brow and a nasty, doubting scowl on your face. Object - oriented design has embraced the heavy constructor model for years. Some of the best books on C++ and C# list countless examples of classes that instantiate their own object instances. After all, isn’t that a facet of well - encapsulated design? The answer of course is yes. All of the tenets of OO design still stand firm. Encapsulation and abstraction are still driving factors of your code design. Loose coupling does not aim to bend the time - honored rules of OO design; rather, it serves to embrace them at a new level. It combines OO methodologies and patterns with a much stronger degree of modularity.
This approach not only yields much more reusability but also enables the designer to achieve perhaps the most important theme of enterprise programming: testability.

Unit Testing

The term unit testing has come to mean many different things over the years. Conceptually, the definition remains the same. A unit test is construct or method for testing the smallest or most finite pieces of your source code. The application of unit tests has varied widely over time. This is especially true when one realizes that the use of unit tests depends entirely on the scope and design of one’s code. There are plenty of systems that do not embrace enterprise programming tenets but that still use unit tests to verify physical layers, individual components, background processes, or other layers that can be divorced from the running system. The problem with this approach is the highly arbitrary nature of the unit. In these looser interpretations of unit tests, the scope of validation usually includes a number of different processes, preventing the ability to truly test at a level where useful action can be taken.
More recent uses of the term unit testing have come to focus on not only the high modular unit of testable code but also on the methodology of testing. In Test Driven Development, or TDD, the developer focuses on writing unit test first, prior to the code it is intended to validate. The programmer then writes the code to fit the test and refractors both in an iterative process.
In the enterprise world, unit tests are pieces of code that complement the modular pieces that make up a system. They almost always employ the use of a unit – testing framework, which is ostensibly another code library with methods that enable test automation. Here in lies one of the fundamental differences between older unit testing and Test Driven Development. The automation of tests is an integral part of the build process. As tests are written and new code checked into your code repository, tests are run against the new code and old code to ensure the durability of the new version of the system. This automation process ensures that developers are quickly alerted of any new code that breaks a previously valid system.

Inversion of Control Containers

As you begin to develop more and more decoupled code, you’ll no doubt begin to feel some strain. Older object - oriented patterns allowed for the provisioning or initialization of complex objects within an object’s constructor. This ensured that, when an object was created, all of its requisite dependencies were created and initialized as well, all from one line of consumer code. The result was simple to use and easy to proliferate. Now, when you strive to decouple your dependencies, you’ll find yourself constantly creating and passing objects into other objects. That’s fine the first time you define your object graph, but it gets very tedious over time. To resolve this tedium, enterprise developers employ the use of an Inversion of Control (IoC) container.
IoC containers, also known as Dependency Injection (DI) containers, help to maintain code modularity while automating a lot of the logic developers would otherwise need to write themselves. They can seem confusing at first as they seem to hide a lot of visible processing. However once you become accustomed to their patterns, they save a lot of time and frustration.

The Enterprise Application Design is still evolving more and more with time, I could not elaborate more on the above but sure you can find a lot of examples online just by providing simple keywords in any search engine.

Keep up the good work and stay tuned

Aspect-Oriented Programming

2011-03-31T00:30:00.007+03:00

The inherent limitations of the OO paradigm were identified quite a few years ago, not many years after the introduction of OOP. However, today AOP still is not widely implemented even though everybody agrees on the benefits it produces. The main reason for such a limited adoption is essentially the lack of proper tools. We are pretty sure the day that AOP is (even only partially) supported by the .NET platform will represent a watershed in the history of AOP.
Wikipedia: Gregor Kiczales started and led the Xerox PARC team that eventually developed AspectJ

Cross-Cutting Concerns

AOP is about separating the implementation of cross-cutting concerns from the implementation of core concerns. For example, AOP is about separating a logger class from a task class so that multiple task classes can use the same logger and in different ways.
We have seen that dependency injection techniques allow you to inject—and quite easily, indeed—external dependencies in a class. A cross-cutting concern (for example, logging) can certainly be seen as an external dependency. So where's the problem?
Dependency injection requires up-front design or refactoring, which is not always entirely possible in a large project or during the update of a legacy system.
In AOP, you wrap up a cross-cutting concern in a new component called an aspect. An aspect is a reusable component that encapsulates the behavior that multiple classes in your project require.

Processing Aspects

In a classic OOP scenario, your project is made of a number of source files, each implementing one or more classes, including those representing a cross-cutting concern such as logging.
In an AOP scenario, on the other hand, aspects are not directly processed by the compiler. Aspects are in some way merged into the regular source code up to the point of producing code that can be processed by the compiler. If you are inclined to employ AspectJ, you use the Java programming language to write your classes and the AspectJ language to write aspects. AspectJ supports a custom syntax through which you indicate the expected behavior for the aspect. For example, a logging aspect might specify that it will log before and after a certain method is invoked and will validate input data, throwing an exception in case of invalid data.

In other words, an aspect describes a piece of standard and reusable code that you might want to inject in existing classes without touching the source code of these classes.

In the AspectJ jargon, the weaver is a sort of preprocessor that takes aspects and weaves their content with classes. It produces output that the compiler can render to an executable.

In other AOP-like frameworks, you might not find an explicit weaver tool. However, in any case, the content of an aspect is always processed by the framework and results in some form of code injection. This is radically different from dependency injection. We mean that the code declared in an aspect will be invoked at some specific points in the body of classes that require that aspect.

Before we discuss an example in .NET, we need to introduce a few specific terms and clarify their intended meaning. These concepts and terms come from the original definition of AOP. We suggest that you do not try to map them literally to a specific AOP framework. We suggest, instead, that you try to understand the concepts—the pillars of AOP—and then use this knowledge to better and more quickly understand the details of a particular framework.

Inside AOP Aspects

As mentioned, an aspect is the implementation of a cross-cutting concern. In the definition of an aspect, you need to specify advice to apply at specific join points.

A join point represents a point in the class that requires the aspect. It can be the invocation of a method, the body of a method or the getter/setter of a property, or an exception handler. In general, a join point indicates the point where you want to inject the aspect's code.

A pointcut represents a collection of join points. In AspectJ, pointcuts are defined by criteria using method names and wildcards. A sample pointcut might indicate that you group all calls to methods whose name begins with Get.

An advice refers to the code to inject in the target class. The code can be injected before, after, and around the join point. An advice is associated with a pointcut.
Here's a quick example of an aspect defined using AspectJ:
public aspect MyAspect
{
// Define a pointcut matched by all methods in the application whose name begins with
// Get and accepting no arguments. (There are many other ways to define criteria.)
public pointcut allGetMethods ():
         call (* Get*() );

// Define an advice to run before any join points that matches the specified pointcut.
before(): allGetMethods()
{
    // Do your cross-cutting concern stuff here
    // for example, log about the method being executed
    .
    .
    .
}
}
The weaver processes the aspect along with the source code (regular class-based source code) and generates raw material for the compiler. The code actually compiled ensures that an advice is invoked automatically by the AOP runtime whenever the execution flow reaches a join point in the matching pointcut.

AOP can be implemented in dot net using the Microsoft's Policy Injection Application Block in Enterprise Library 3.0 and higher. You can check it on MSDN Magazine or at Programming Help

Hoping that this topic has brought to you a wider vision about AOP, stay tuned for some examples of implementing AOP in Dot Net 4.0

Universal Software Principles

2011-03-27T02:41:00.003+03:00

Maintainability is the fundamental attribute of modern software. The importance of maintainability spans the technology spectrum and applies to the Web as well as desktop applications.

A few universally valid design principles help significantly to produce code that is easier to maintain and evolve. It is curious to note that they are all principles devised and formulated a few decades ago. Apparently, for quite some time we’ve had the tools to build and manage complex software but real applications were just lacking the complexity to bring them to the forefront as design best practices. This is also my interpretation of the advent of the Rapid Application Development (RAD) paradigm a decade ago, which complemented (and in some cases superseded) object-oriented programming (OOP).

Today, the situation is different. With large companies now taking full advantage of Internet, cloud, and mobile computing, developers and architects are swamped with an incredible amount of complexity to deal with. That’s why RAD is no longer sufficient in many scenarios. On the other hand, not everybody is skilled enough to use OOP. It’s about time we all rediscover some fundamentals of software programming—regardless of the type of application we’re building.

Summarizing, I would boil software principles down to two principles: the High Cohesion and Low Coupling principle and the Separation of Concerns principle.

Cohesion and Coupling

Cohesion and coupling go hand in hand even though they refer to orthogonal aspects of your code. Cohesion leads you toward simple components made of logically related functions—kind of atomic components. Coupling indicates the surface area between two interfacing components: the wider the area is, the deeper the dependency is between the components. The magic is all in finding the right balance between cohesion and coupling while trying to maximize both.

Cohesion at a Glance

Cohesion indicates that a given software module—a class, if we assume the object-oriented paradigm—features a set of responsibilities that are strongly related. Put another way, cohesion measures the distance between the logic expressed by the various methods on a class.

If you look for a moment at the definition of cohesion in another field—chemistry—you can get a clearer picture of software cohesion. In chemistry, cohesion is a physical property of a substance that indicates the attraction existing between like-molecules within a body.

Cohesion measurement ranges from low to high, with the highest possible cohesion being preferable. Highly cohesive modules favor maintenance and reusability because they tend to have no dependencies. Low cohesion, on the other hand, makes it much harder to understand the purpose of a class, and it creates a natural habitat for rigidity and fragility in your software. Low-cohesive modules also propagate dependencies, thus contributing to the immobility and viscosity of the design.

Decreasing cohesion leads to creating classes where methods have very little in common and refer to distinct and unrelated activities. Translated into a practical guideline, the principle of cohesion recommends creating extremely specialized classes with few methods that refer to logically related operations. If the “logical” distance between methods needs to grow, well, you just create a new class.

Coupling at a Glance

Coupling measures the level of dependency existing between two software classes.

An excellent description of coupling comes from the Cunningham wiki

Two classes, A and B, are coupled when it turns out that you have to make changes to B every time you make any change to A. In other words, B is not directly and logically involved in the change being made to module A.

However, because of the underlying dependency B is forced to change; otherwise, the code won’t compile any longer.

Coupling measurement ranges from low to high, with the lowest possible coupling being preferable.

Low coupling doesn’t mean that your modules have to be completely isolated from one another. They are definitely allowed to communicate, but they should do that through a set of well-defined and stable interfaces. Each class should be able to work without intimate knowledge of the internal implementation of another class. You don’t want to fight coupling between components; you just want to keep it under control. A fully disconnected system is sort of nonsense today.

Conversely, high coupling hinders testing and reusing and makes understanding the system nontrivial. It is also one of the primary causes of a rigid and fragile design.

Low coupling and high cohesion are strongly correlated. A system designed to achieve low coupling and high cohesion generally meets the requirements of high readability, maintainability, easy testing, and good reuse.

Separation of Concerns

Functional to achieving high cohesion and low coupling is the separation of concerns (SoC) principle, introduced by Edsger W. Dijkstra in his paper “On the role of scientific thought” which dates back to 1974. If you’re interested, you can download the full paper

Identifying the Concerns

SoC is all about breaking the system into distinct and possibly non-overlapping features. Each feature you want in the system represents a concern and an aspect of the system. Terms like feature, concern, and aspect are generally considered synonyms. Concerns are mapped to software modules and, to the extent that it is possible, there’s no duplication of functionalities.

SoC suggests that you focus your attention on one particular concern at a time. It doesn’t mean, of course, that you ignore all other concerns of the system. More simply, after you’ve assigned a concern to a software module, you focus on building that module. From the perspective of that module, any other concerns are irrelevant.

Modularity

SoC is concretely achieved through modular code and making large use of information hiding.
Modular programming encourages the use of separate modules for each significant feature.
Modules are given their own public interface to communicate with other modules and can contain internal chunks of information for private use.

Only members in the public interface are visible to other modules. Internal data is either not exposed or it is encapsulated and exposed in a filtered manner. The implementation of the interface contains the behavior of the module, whose details are not known or accessible to other modules.

Information Hiding

Information hiding (IH) is a general design principle that refers to hiding behind a stable interface some implementation details of a software module that are subject to change. In this way, connected modules continue to see the same fixed interface and are unaffected by changes.

A typical application of the information hiding principle is the implementation of properties in Microsoft C# or Visual Basic .NET classes. The property name represents the stable interface through which callers refer to an internal value. The class can obtain the value in various ways (for example, from a private field, from a control property, from a cache, and from the view state in ASP.NET) and can even change this implementation detail without breaking external code.

Information hiding is often referred to as encapsulation. I like to distinguish between the principle and its practical applications. In the realm of object-oriented programming, encapsulation is definitely an application of IH.

In general, though, the principle of SoC manifests itself in different ways in different programming paradigms, and so it is also for modularity and information hiding.

I guess some of you know these principles, but others not so let's act community
Stay Tuned :)

Preprocessor Directives C# 4.0

2011-03-22T01:30:00.003+02:00

What Are Preprocessor Directives?

The source code specifies the definition of a program. The preprocessor directives instruct the compiler how to treat the source code. For example, under certain conditions, you might want the compiler to ignore portions of the code, and under other conditions, you might want that code compiled. The preprocessor directives give you those options and several others.

In C and C++ there is an actual preprocessor phase, in which the preprocessor goes through the source code and prepares an output stream of text to be processed by the subsequent compilation phase. In C# there is no actual preprocessor. The “preprocessor” directives are handled by the compiler. The term, however, remains.
Preprocessor List:

#define identifier: Defines a compilation symbol

#undef identifier: Undefines a compilation symbol

#if expression: If the expression is true, compiles the following section

#elif expression: If the expression is true, compiles the following section

#else: If the previous #if or #elif expression is false, compiles the following section

#endif: Marks the end of an #if construct

#region name: Marks the beginning of a region of code; has no compilation effect

#endregion name: Marks the end of a region of code; has no compilation effect

#warning message: Displays a compile-time warning message

#error message: Displays a compile-time error message

#line indicator Changes: the line numbers displayed in compiler messages

#pragma text: Specifies information about the program context

The #define and #undef Directives

A compilation symbol is an identifier that has only two possible states. It is either defined or undefined. A compilation symbol has the following characteristics:

• It can be any identifier except true or false. This includes C# keywords and identifiers declared in your C# code—both of which are fine.

• It has no value. Unlike in C and C++, it does not represent a string.

• The #define directive declares a compilation symbol.

• The #undef directive undefines a compilation symbol.

The #define and #undef directives can be used only at the top of a source file, before any C# code is listed. After the C# code has started, the #define and #undef directives can no longer be used.

The scope of a compilation symbol is limited to a single source file. Redefining a symbol that is already defined isperfectly fine—as long as it’s before any C# code, of course.

Conditional Compilation

Conditional compilation allows you to mark a section of source code to be either compiled or skipped, depending on whether a particular compilation symbol is defined.

There are four directives for specifying conditional compilation:

• #if

• #else

• #elif

• #endif

A condition is a simple expression that returns either true or false.

• A condition can consist of a single compilation symbol or an expression of symbols and operators, as summarized below Subexpressions can be grouped with parentheses.

• The literals true and false can also be used in conditional expressions.

Parameter Type: Compilation symbol
Meaning: Identifier, defined (or not) using the #define directive
Evaluation: True: If the symbol has been defined using a #define directive False: Otherwise

Parameter Type: Expression
Meaning: Constructed using symbols and the operators !, ==, !=, &&,
Evaluation: True: If the expression evaluates to true False: Otherwise

The Conditional Compilation Constructs

The #if and #endif directives are the matching demarcations of a conditional compilation construct. Whenever there is an #if directive, there must also be a matching #endif. Figure below illustrates the #if and #if...#else constructs.

• If the condition in the #if construct evaluates to true, the code section following it is compiled. Otherwise, it is skipped.

• In the #if...#else construct, if the condition evaluates to true, CodeSection1 is compiled. Otherwise, CodeSection2 is compiled.

• In the #if...#elif construct, if Cond1 evaluates to true, CodeSection1 is compiled, and compilation continues after the #endif.

— Otherwise, if Cond2 evaluates to true, CodeSection2 is compiled, and compilation continues after the #endif.

— This continues until either a condition evaluates to true or all the conditions have returned false. If that’s the case, none of the code sections in the construct are compiled, and compilation continues after the #endif.

• The #if...#elif...#else construct works the same way, except that if no condition is true, then

the code section after the #else is then compiled, and compilation continues after the #endif.

Diagnostic Directives

Diagnostic directives produce user-defined compile-time warning and error messages.

The following is the syntax of the diagnostic directives. The messages are strings, but you will notice that unlike normal C# strings, they do not have to be enclosed in quotation marks.

#warning Message

#error Message

When the compiler reaches a diagnostic directive, it writes out the associated message. The diagnostic directive messages are listed by the compiler along with any compiler-generated warning and error messages.

Line Number Directives

Line number directives can do several things, including the following:

• Change the apparent line numbers reported by the compiler’s warning and error messages

• Change the apparent file name of the source file being compiled

• Hide a sequence of lines from the interactive debugger

Region Directives

The region directive allows you to mark, and optionally name, a section of code. The characteristics of the #region directive are the following:

• It is placed on the line above the section of code you want to mark.

• It can take an optional string of text following it on the line, which serves as its name.

• It must be terminated by an #endregion directive, further down in the code.

Although region directives are ignored by the compiler, they can be used by source code tools.

Visual Studio, for example, allows you to easily hide or display regions.

The #pragma warning Directive

The #pragma warning directive allows you to turn off warning messages and to turn them back on.

• To turn off warning messages, use the disable form with a comma-separated list of warning numbers you want to turn off.

• To turn warning messages back on, use the restore form with a list of the warning numbers you want to turn back on.

It is considered very important strategy to consider adding directives in your code, it will take the compilation time into the next level and will enhance your code.

Future examples will be posted to demonstrate the practical usage of directives

Stay tuned... Developers

Free Dot Net Source Control System For Group Development

2011-03-14T23:50:00.002+02:00

I guess many of the dot net developers are working in groups inside a company or within the same district and need to sync their files and work on the same project source without having to take it from a machine to another.

Also Individual developers, who are working from their homes using desktops and laptops, want a way to synchronize their work without using any external drive for file transfer.

The first way that everyone knows is the Visual Source Safe or the most famous Team Foundation Server, the VSS uses the file system to store the data while the TFS uses a database and both are supported. These two source control systems are used within an intranet (between computers in the same LAN) and both are costly.

Small group of developers can not afford such product or don’t want to use it and still have the need for code redistribution.

The solution is a free online repository (SVN), this type of source control is well known inside the Java community but not spread inside the Microsoft community.

Let’s dive deep inside the “How to integrate SVN into Visual Studio (our famous tool)”

First you need to install the SVN plug-in for visual studio, I have chosen the free AnkhSvn, you can download it and install it for free into your visual studio.

After the installation finishes, reopen your visual studio you will see the subversion-> open from Subversion option from the file menu as shown below

Now, it is the time to create the repository to connect to, one of the free online repository and a safe one is the Assembla. You can find another with a simple search keyword “Free svn repository”.

Create a new account or use your already existing Google account to have your own repository.

After creating your space your folder is ready and you have your repository URL (check the figure below)

You will notice that a trunk folder is already created, this is a Java tradition :) you need just to add your project inside it, and here you go.

Now you are online and you can sync and submit your files anywhere with just an internet connection and some clicks. Open your solution or create new one and submit it easily

One of the good options in the SVN is the “ChangeLists” where you can revert files with a specific revision or submit date. (Figure below)

You can check what are the actions on subversion and what is SVN (original one) check Subversion

Now you have your project hosted on the cloud, you can add files, checkout files and/ or submit files into it, you can even backup your database and add it on the repository, or just upload the sql script to it.

Try it; it is fascinating and so easy to assemble…

Have a nice software day.

Active Directory Membership Provider

2011-03-10T01:49:00.004+02:00

I have noticed that most of the developers are eager to learn about active directory connection and membership for ASP.net, I have provided an old post about the subject but I noticed it was attractive to many users who needed more info.

Working with Active Directory

Out of the box, there is a reasonably high likelihood that you can get the provider to start working with an AD domain. Because the first hurdle you will face is the question of connectivity to the directory, getting the correct connection string is important. Luckily, if you know what your options are it is alsopretty easy to setup. For starters, you can configure a sample application with the provider that attempts to retrieve a user object from the Users container that is found on all domains. Because ActiveDirectoryMembershipProvider is not configured in either machine.config or the root web.config files, you will need to explicitly configure it in web.config.

<membership defaultprovider="appprovider">
<providers>
<clear/>
<add name="appprovider" type="System.Web.Security.ActiveDirectoryMembershipProvider, ..." connectionStringName="DirectoryConnection">
</providers>
</membership>

Because none of the other provider-specific configuration options are used, the provider will connect to the directory using the underlying process credentials. This is an important point because it means that, by default, when running on IIS6 the provider will connect to your directory as NETWORK SERVICE (that is, the machine account from the perspective of the directory server). For now, let’s use a connection string that looks like:

<connectionstrings> <add connectionstring="LDAP://myADServer.com" name="DirectoryConnection">
</connectionstrings>

This style of connection string tells the provider to explicitly connect to a specific directory server. Note, though, that there is no other information in the connection string, which means that the provider will automatically attempt to bind to the Users container. To see whether this configuration works, a simple test page writes out some of the properties of a user that already exists in the directory:

MembershipUser mu = Membership.GetUser(“user@myADServer.com”);
Response.Write("Email address is: " + mu.Email + "");
Response.Write("Creation date is: " + mu.CreationDate.ToString() + "");
When I ran this sample app against a directory server, the following information was returned:
Email address is: user@myADServer.com
Creation date is: 3/6/2005 1:12:57 PM

This isn’t exactly earth-shattering information, but if you think about it, with only some standard configuration entries and some boilerplate Membership code, you are now accessing a user object in a directory.

No need for kung-fu coding with classes in the System.DirectoryServices namespace let alone mucking around with the older ADSI programming APIs.

You can make things more interesting by first trying different variations of the connection string. One variation simply points the application at the domain, as opposed to a domain controller.

<add connectionstring="LDAP://myADServer.com"
name="DirectoryConnection">

Notice how the connection string no longer points at a specific server. Now the provider is simply leveraging the default connectivity behavior supported by AD where you can just supply the DNS name associated with the domain and the underlying network stack performs the magic of looking up special directory service entries in DNS to route the request to an actual domain controller. Although this type of connection string is interesting to know about, and it can be useful in a development environment just to get things up and running, in an extranet environment you need to be careful with this type of connection string. Because you aren’t guaranteed a connection to any specific directory controller, you can end up in cases where an operation against a user object occurs against one domain controller, and then at a later point in time the provider connects to a different controller that has not yet received the replicated changes. This behavior is not a bad thing; you just need to be aware of whether your application can tolerate this. The nice thing about a serverless connection string is that your application isn’t tied to the uptime of any specific directory server. Instead, the provider will connect to whatever is available, and if a DC goes down then the provider will simply be routed to a different server.

Another connection string variation (and probably the most common one you will use) includes the container name.

<add name="DirectoryConnection"

connectionString="LDAP://myAdServer.com/CN=Users,DC=myAdServer,
DC=com">

With this connection string, the provider will bind to the container specified after the server name. In this case, the connection string is binding to the Users container. If you have ever used ADSI or System. DirectoryServices, this should be a familiar syntax to you for binding to the Users container.

If you use the provider in an extranet environment where different user populations are segmented into different organizational units (that is, OUs), then you would use a connection string like the following:

<add name="DirectoryConnection"
connectionString="LDAP://myAdServer.com/OU=UserPopulation_A,DC=myAdServer,
DC=com">

Now instead of referencing a built in container, the connection string references an OU that was created in the domain. In this case, the OU is a peer of the Users container. However, you can just as easily bind to OUs that are nested any number of levels deep.

<add name="DirectoryConnection"
connectionString="LDAP://myAdServer.com/OU=SomeNestedOU,OU=UserPopulation_A,DC=myAdServer,
DC=com">

For nested containers, you just build up the second part of the connection string with the walk-up path from the nested OU to the top of the container hierarchy.

Active Directory Schema Mappings

By default the provider attempts to map the properties of the MembershipUser class to an appropriate set of default attributes on the user class in AD and ADAM. Some aspects of this mapping are configurable, whereas other aspects are not. The most important constraint is that ActiveDirectoryMembershipProvider always binds to objects of type user. Although in Windows Server 2003 and ADAM the ability to use inetOrgPerson was added, the provider currently only supports binding to objects of type user.

The following properties on MembershipUser have fixed schema mappings to attributes in the directory:

ProviderUserKey: This value maps to the objectSID attribute on the user object. As a result, you can get the user’s security identifier (SID) from the ProviderUserKey property and you can also retrieve MembershipUser instances using the SID as a key.

Comment: Maps to the comment attribute on the user class.

CreationDate: Maps to the whenCreated attribute on the user class.

LastPasswordChangedDate—Maps to the pwdLastSet attribute on the user class.

IsApproved: Maps to the userAccountControl attribute when using AD. Maps to the mDSUserAccountDisabled attribute when using ADAM.

IsLockedOut: Maps to msDS-User-Account-Control-Computed attribute when using AD on Windows Server 2003 or when using ADAM. This property is computed from the lockoutTime attribute and the directory’s account lockout duration setting when running against Windows 2000 AD (W2K’s schema did not include the msDS-User-Account-Control-Computed attribute). If you have configured the provider to support question-and-answer-based password reset, then the provider will also look at the custom tracking information for bad password answers when determining whether a user is considered locked out.

LastLockoutDate: Maps to the lockoutTime attribute on the user class. If question-andanswer-based password reset has been enabled, then the lockout date may also come from the custom attributes that track bad password answer attempts.

Other properties on MembershipUser are either not mapped by default or have default mappings to directory attributes that you can change.

Username—By default, the provider maps this property to the userPrincipalName attribute in the directory. This mapping will work for you if each of your directory users is created with a user principal name. For older directories, though, you may be using the NT4-style SAM account names, in which case you will need to change the mapping for this property. You can change the mapping to the sAMAccountName attribute in this case. Note that if you try to use the provider with an already populated directory, and you are scratching your head wondering why you can’t find any users or successfully validate any credentials, it is probably because your users have SAM account names, but you have not configured the provider to use the SAMAccountName attribute for MembershipUser.Username.

Email—By default, the provider maps this property to the mail attribute. If you want, you can change this mapping to any single-valued attribute on the user class that is of type Unicode String.

PasswordQuestion: This property is not mapped by default to anything in the directory. If you intend to use question-and-answer-based password resets with the provider, there are actually five different attributes that need to be mapped on the user class. The section on “Working with Active Directory” walks you through adding custom attributes to the AD schema and setting up password reset functionality.

Because Active Directory operates in a multimaster environment, some of the properties on MembershipUser cannot be reliably implemented based on directory attributes.

LastActivityDate: This property has no mapping and is not supported by the provider.

There is no concept in either AD or ADAM of touching the user object every time something happens. Unlike the SQL providers where different features all update a LastActivityDate column in the database, attempting to engineer a similar approach for AD wasn’t feasible. First, there would be no way for other features such as Profile to reach into a user object in a directory and update an arbitrary field (suddenly you would have System.DirectoryServices code sitting in the middle of the SQL provider code, which would be a bit strange to say the least).

Another problem is that for this value to make any sense in a multimaster environment you would have to replicate the field to all of the various domain controllers. Because it isn’t likely that most customers would want to add a custom attribute and then replicate it across their domain infrastructure each and every time the attribute was changed, the decision was made not to support the concept of a last activity date for the provider.

LastLoginDate: Both AD and ADAM store the last logon time for a user using the lastLogon and lastLogonTimestamp attributes, respectively. However, these attributes aren’t replicated across domain controllers, and the property is not available from the global catalog.

So, it is very likely that the provider would either get differing values for this property or stale property values in any domain that had at least two domain controllers. Rather than having the provider iterate through all domain controllers in a domain attempting to find the latest value the decision was made to not implement this property.

If you want to change any of the configurable attribute mappings for the provider, you can do so by using the following configuration attributes in the provider’s element:

attributeMapUserName: You can use this provider configuration attribute to change which attribute on the user class the provider uses for identifying a user. You can set this to either userPrincipalName (the default) or to sAMAccountName.

attributeMapEmail: If you don’t want to store user’s email addresses in the default mail attribute, you can tell the provider to use a different directory attribute instead. The only restriction is that that the directory attribute must be of type Unicode String.

attributeMapPasswordQuestion: This configuration attribute must be defined for the provider if you set enablePasswordReset to true. The configuration attribute must reference a directory attribute of type Unicode String.

attributeMapPasswordAnswer This configuration attribute must be defined for the provider if you set enablePasswordReset to true. The configuration attribute must reference a directory attribute of type Unicode String.

attributeMapFailedPasswordAnswerCount: This configuration attribute must be defined for the provider if you set enablePasswordReset to true. The configuration attribute must reference a directory attribute of type Integer.

attributeMapFailedPasswordAnswerTime: This configuration attribute must be defined for the provider if you set enablePasswordReset to true. The configuration attribute must reference a directory attribute of type Large Integer/Interval.

attributeMapFailedPasswordAnswerLockoutTime: This configuration attribute must be defined for the provider if you set enablePasswordReset to true. The configuration attribute must reference a directory attribute of type Large Integer/Interval.

Along with the directory schema mappings comes a set of default size restrictions on the length of various string properties. With the SQL provider, it is pretty easy to determine length restrictions by just looking in the database at the column definitions. For the AD provider, this is harder to accomplish unless you can look at the actual directory schema. The default length restrictions for various MembershipUser-related properties are shown in the following list. Note though that it is possible for you to edit the AD and ADAM schemas to enforce even shorter size restrictions. If you have done this, the provider will honor the size restrictions defined in your directory’s schema.

Username: If you mapped username to sAMAccountName then your username cannot be longer than 20 characters. This is a hard-coded size restriction from NT4 days. If you mapped username to userPrincipalName, then a username cannot be longer than 64 characters.

Password: As with the SQL provider, the plaintext password for a user cannot be longer than 128 characters.

Comment: The provider only allows comments up to 1024 characters in length. This differs from the SQL provider, where you could basically store the entire English dictionary if you wanted in a user’s Comment property.

Email—A user’s email property cannot be longer than 256 characters.

PasswordQuestion: A user’s password question cannot be longer than 256 characters.

PasswordAnswer: A user’s cleartext password answer cannot be longer than 128 characters.

However, the end result of encrypting the password answer also cannot be longer than 128 characters.

Because the ActiveDirectoryMembershipProvider always encrypts the password answer

using the same encryption method for SqlMembershipProvider, this limits users to around a 42-character long cleartext password answer.

Hope I have addressed useful information about Active Directory, wait more post to come

Software Skills (The Art of Software Development)

2011-03-08T23:55:00.002+02:00

Simply put, soft skills are the ability to communicate with people. They are the skills that make customers feel happy. They are the skills that keep customers, make individuals valuable. So, if you’re wondering what the incentive is to brush up on this skill set—its money, baby!

To a technical person, anything outside of product and development skills could be considered soft skills, but here’s an unofficial list of soft skills for technical people and why they’re important. These are as follows.

Project management:
Project management goes beyond learning Microsoft Project or any other software. Success as a project manager depends on your ability to define, plan, organize, control, and complete a variety of complex and interdependent tasks.

Communication:
Whether answering the phone, writing an e-mail, or putting together a proposal, how well you put your point across affects others’ perceptions of your abilities. Make sure each interaction paints an intelligent picture.

Presentation:
Forget the horror of high school oral-communications classes. These skills are a must for any situation—from running a meeting to pitching a product or solution, or justifying why you should get that raise. It doesn’t matter how many are in the audience; every time you open your mouth, you are using these skills. Make sure you’re presenting the image you want by mastering this skill set.

Selling:
Face it; regardless of whether your title includes “sales,” you’re always selling. Whether it’s yourself, your project, or your next position, you’re always asking people to buy in on something. Learn how to do it more effectively and do it eagerly.

Running meetings:
Learning how to facilitate meetings and manage group interactions is an important first step to becoming a team leader.

Leadership:
Successful projects have many keys, including organizational buy-in, good project management, and proper resourcing. A strong leader understands these dynamics, harnesses the diverse energies within an organization, and pulls everyone together. It’s about knowing your resources and key points.

Problem-solving:
This is the skill you are probably most familiar with. To some, problem solving comes instinctively. To others, it’s not so natural. The key is to find a process that works and apply it.

Customer service:
Yes, people are difficult. But, when they’re customers, they come first and they’re always right. They need to feel valued and important. Just remember: if you don’t treat them right, someone else will. This is your main target to get a value.

Self-direction:
This is the ability to do your job without having to be told how to do your job. It’s extremely important, because by the time your manager gets through telling you how to do it, he/she could have probably done it himself/herself.

Teamwork:
No man is an island, certainly not in IT where there isn’t room for egos. With so many different operating systems (OSs), servers, networks, databases, and other things that need to be coordinated, no one can do it alone. Here’s where those skills you learned in kindergarten come in: sharing, saying “please,” and—more importantly—saying “thank you.” Play nicely with others or take a time-out.

Unfortunately, as any five-year-old can tell you, knowing how to share isn’t the same as doing it. You can’t learn soft skills unless you practice them. And this top-ten list is worth more than a few quick laughs—it can be your ticket to a highly successful IT career. Take a look at your current situation and see how you’ve managed to put these skills into practice.

This topic will be followed by similar posts later, all of which will be addressing how to improve and maintain your soft skills. Nothing comes without effort.

The MVP Pattern

2011-03-04T11:55:00.003+02:00

MVP is a derivative of MVC aimed at providing a cleaner separation between the view, the model, and the controller. The most relevant change from MVC is that view and model are physically separated and have no intimate knowledge of each other. The controller (renamed as presenter) is a mediator between the user and the application. Solicited by the view, it performs any work associated with the request and passes data back to the view. In MVP, the controller class is essentially responsible for presenting data to the view, which explains the new name of “presenter.”

Generalities of the MVP Pattern

As mentioned, in MVP the view and the model are neatly separated, and the view exposes a contract through which the presenter can read input values and provide results of the action.
Summarizing the situation further, we can say that MVP is a refinement of MVC based on three facts:
■ The view doesn’t know the model.

■ The presenter ignores any UI technology behind the view.

■ Abstracted to an interface, the view is easy to mock up, which makes testing the controller far easier.

The presenter is at the center of the universe and incorporates the presentation logic behind the view. The presenter in MVP is logically bound to the view, which is another reason for emphasizing the presentation role of the component. ASP.Net MVP Framework

Comparison of MVC and MVP graphically

Role of the Model

The best possible definition of the model doesn’t change in MVP. The model is the representation

of the data being worked on in the view. The above figure exposes a contracted interface, which represents the core functionality of the view to the presenter’s eyes. In other words, the presenter should be able to work with any object that implements that contracted interface.
In theory, it could be an ASP.NET page as well as a Windows Forms window. The model in MVP, therefore, is the interface that the view object implements. Being an interface, it can include properties, but it can also include methods and events. In a Web Forms scenario, events are not required, and most of the time it will contain just properties.

Role of the View

The view is the Web Forms page that you build. This view is typically an instance of a class that inherits from Page or UserControl and implements the model. The view also holds a reference to an instance of the presenter. Between views and presenters, you typically have a one-to-one cardinality, even though you can still reduce the number of presenter classes by creating some sort of hierarchy and reusing a bit of code.

Role of the Presenter

The presenter is just an additional layer you build on top of code-behind classes. It is a class that can be easily designed to have no hidden dependencies. The presenter requires a reference on the view, but thanks to the contracted interface of the view the reference can be injected. The presenter will use the view object to grab input values and prepare a call to the middle tier. After the response has been received, the presenter will pass data back to the view, always through the members of the interface. As mentioned, the interface that abstracts the view is logically equivalent to the model in MVC. you can check it at MSDN at Model-View-Presenter Pattern

Web Forms and the MVP Pattern

MVP lends itself very well to being implemented in Web Forms. The pattern can be easily outlined as a step-by-step procedure and doesn’t require you to twist the Web Forms programming model. As a developer, you only need to add a bit of abstraction to your Web Forms pages to gain the benefits of the MVP pattern—testability and maintainability.

Having said that, I also feel obliged to mention that MVP is not a pattern for everyone and for just any application. MVP provides guidance on how to manage heaps of views and, quite obviously, comes at a cost—the cost of increased complexity in the application code. As you can imagine, these costs are easier to absorb in large applications than in simple ones. MVP, therefore, is not just for any application.

In MVP, the view is defined through an interface, and this interface is the only point of contact between the system and the view. As an architect, after you’ve abstracted a view with an interface, you can give developers the green light to start developing presentation logic without waiting for designers to produce the graphics. After developers have interfaces, they can start coding and interfaces can be extracted from user stories, if not from full specifications.

MVP is an important presentation pattern that can be a bit expensive to implement in relatively simple applications. On the other hand, MVP shines in enterprise-class applications, where you really need to reuse as much presentation logic as possible, across multiple platforms and in Software-as-a-Service (SaaS) scenarios. And many of these applications have an ASP.NET Web Forms front end.

Another full article about MVP is introduced at MSDN Magzine http://msdn.microsoft.com/en-us/magazine/cc188690.aspx

Custom Paging GridView (Inheriting from the Base GridView Control)

2011-02-26T01:01:00.001+02:00

Developers, you are trying to implement custom paging for ASP.net GridView and sure you have read many posts and information about this subject.

Many posts used this by applying external pagers outside the GridView. this is over :) lets use iheritance to implement that:

Create the extension class CustomPagingGridView that inherits GridView as follows:

public class CustomPagingGridView : GridView

{
public CustomPagingGridView()
: base()
{
this.AllowPaging = true;
this.AllowSorting = true;
this.PagerSettings.Mode = PagerButtons.NumericFirstLast;
}

#region Custom properties

[Browsable(true), Category("Updated")]
[Description("Set the Database table total item count for this grid")]
public int TotalDatabaseItemCount
{
get
{
if (ViewState["pgv_vitemcount"] == null)
ViewState["pgv_vitemcount"] = -1;
return Convert.ToInt32(ViewState["pgv_vitemcount"]);
}
set
{
ViewState["pgv_vitemcount"] = value;
}
}

[Browsable(true), Category("Updated")]
[Description("Get the item ordering when sorting event is triggered")]
public string OrderBy
{
get
{
if (ViewState["pgv_orderby"] == null)
ViewState["pgv_orderby"] = string.Empty;
return ViewState["pgv_orderby"].ToString();
}

protected set
{
ViewState["pgv_orderby"] = value;
}
}

private int CurrentPageIndex
{
get
{
if (ViewState["pgv_pageindex"] == null)
ViewState["pgv_pageindex"] = 0;
return Convert.ToInt32(ViewState["pgv_pageindex"]);
}
set
{
ViewState["pgv_pageindex"] = value;
}
}

private bool CustomPaging
{
get
{
return (TotalDatabaseItemCount != -1);
}
}
#endregion

#region Overriding the parent methods

public override object DataSource
{
get
{
return base.DataSource;
}
set
{
base.DataSource = value;
CurrentPageIndex = PageIndex;
}
}

protected override void OnSorting(GridViewSortEventArgs e)
{
SortDirection direction = SortDirection.Ascending;
if (ViewState[e.SortExpression] != null && (SortDirection)ViewState[e.SortExpression] == SortDirection.Ascending)
{
direction = SortDirection.Descending;
}
ViewState[e.SortExpression] = direction;
OrderBy = string.Format("{0} {1}", e.SortExpression, (direction == SortDirection.Descending ? "DESC" : ""));
base.OnSorting(e);
}

protected override void InitializePager(GridViewRow row, int columnSpan, PagedDataSource pagedDataSource)
{
if (CustomPaging)
{
pagedDataSource.AllowCustomPaging = true;
pagedDataSource.VirtualCount = TotalDatabaseItemCount;
pagedDataSource.CurrentPageIndex = CurrentPageIndex;
}
base.InitializePager(row, columnSpan, pagedDataSource);
}

#endregion

}

When you include this class within your code and compile, a "CustomPagingGridView" will be added in the toolbar under the pointer icon while opening any aspx file

Add it to your design view and set its properties as desired.

Properties:

when clicking on the newly added custom gridview in the properties part, a new section named "Updated" is added containing two properties that can be programmatically set, these properties are "TotalDatabaseItemCount" and "OrderBy"

The total database item count is the total number to be fetched for example if you want to fetch 1000 item from database 10 by 10 (1000 is the count to be fetched ex “select Count(*) from table1")

Next you have to set the TotalDatabaseItemCount=1000 and get records from database 10 by 10 using inline stored procedure or inner query “select * from table1 where rownum>10 && rownum<20” this will fetch the first bulk.

In the previous example we are getting the second page of the gridview if we has a pager of 10, note that the number can be populated from the current index and page number.

Hope this will be useful. Feel free to ask any question or inquire about any example.

DOT NET 4.0 LINQ to Services (LINQ to Amazon, google, bing, JSON, LDAP (Active Directory), Streams, DryadLINQ …)

2011-02-21T23:35:00.006+02:00

THE HIDDEN PART OF LINQ -you will discover an amazing abilities of LINQ-

LINQ to Services
In the real world, many widely used services already have LINQ implementations. Most of these implementations are community based and are not officially supported by single-service providers.
One of the first LINQ wrappers to an external service was LINQ to Amazon. Using this service,you can look for books in the Amazon catalog, filtering them by attributes such as publisher,price, title,and so on. Similarly, by using LINQ to Flickr (http://linqflickr.codeplex.com), you can search for photos stored in the Flickr photo-sharing service. LINQ to Flickr also offers support for adding or deleting photos, a feature not directly tied to the LINQ query syntax, but which is conceptually similar to the entities you can manage in LINQ to SQL or LINQ to Entities.

Google is another source for accessing data through remote services. The LINQ to Google implementation actually supports only queries to Google Base, which is a search engine that can index structured entities decorated with customizable attributes.

The presence of these attributes makes the use of LINQ meaningful, because you can include them as part of a LINQ query, as shown in the following example:
GoogleItems.GoogleContext gc = new GoogleItems.GoogleContext(key);
var r = from car in gc.products
where car.Brand == “car” && car.Price < 5400
select new { car.Title, car.Price };

The Bing search engine offers a LINQ to Bing provider, which is part of the Web Application Toolkit for Bing Search. This provider supports searches on webpages, news, images, and video. Here is an example of a Bing web

query:
Linq2Bing lb = new Linq2Bing();
var query = from w in lb.Web
where w.Text == “test” && w.Text == “test1”
select w;

Yet another LINQ implementation that could be useful for accessing remote services is LINQ to JSON, which is included in Microsoft Silverlight and accessible through the System.Json namespace. Another implementation you can use without Silverlight is the Json.NET 3.5 library. This implementation provides a LINQ-integrated model that simplifies access from a .NET Framework application to data serialized with JSON.

Simplifying access to remote services that provide integration with LINQ queries is an area that will likely see great expansion in the future. The service provider does not need to define its own LINQ wrapper; any service consumer can write a LINQ wrapper for that service. However,the most widely used services will probably be supported either directly by service providers or by projects that are supported by communities.

LINQ for System Engineers
Applications that control an existing infrastructure or that automate administrative tasks might be able to take advantage of LINQ while accessing specific services and APIs useful for their needs.

LINQ to Active Directory is an implementation that simplifies access to Active Directory APIs, such as System.DirectoryServices (.NET) and ActiveDs (COM).

The same author originally wrote (and analytically described) a more general implementation of LINQ to LDAP.

Another interesting LINQ implementation is one that provides access to Windows Management Instrumentation (WMI). check implementation of LINQ to WMI . By using a provider like this, you can query WMI counters in a simple and declarative way.

Dynamic LINQ

The standard result of a LINQ query is considered to be static. It does not change after query execution. However, there are situations in which the definition of a LINQ query should be more dynamic, acting more as a filter in a stream of data or making the query result “live.”

The LINQ to Streams implementation focuses on streaming data those changes in real time. Currently, it is a simple prototype, but the approach seems interesting for particular scenarios such as network monitors, financial services, and real-time data acquisition.

Another approach to the same issue is the one used in SyncLINQ. This implementation is focused more on data binding over LINQ queries. To support dynamic updates of the query result, a SyncLINQ query returns collections that implement INotifyCollectionChanged, which is the interface provided by the .NET Framework to notify listeners of dynamic changes. The SyncLINQ implementation should establish compatibility with existing user interface components that support INotifyCollectionChanged.

These implementations do not provide a solution for every tier of an application’s architecture, but they do present an interesting approach to solving some of the issues regarding the use of a common programming pattern (LINQ queries). These implementations attempt to simplify and encapsulate the work necessary to handle dynamic updates to data returned from a query.

Other LINQ Enhancements and Tools

DryadLINQ is a research project that uses LINQ to access Dryad, a distributed execution engine. DryadLINQ compiles lambda expressions into DLLs and routes the DLLs to remote machines for execution. This is a more complex form of parallelism than the one offered by PLINQ and is an interesting implementation for very CPU-intensive applications.

Indexed LINQ, also known as I4O, is a class library through which you can create indexes on objects queried using LINQ to Objects. This implementation is particularly interesting for applications that load and maintain a large number of objects in memory. Using optimizations like the one provided by I4O, any object graph in memory can seem like an in-memory database, even if LINQ and I40 do not automatically solve the issues of concurrent access in a multithreaded environment.

LINQExtender is a tool for building LINQ providers. The LINQ to Flickr provider mentioned earlier was created using this tool. The tool is particularly interesting because it provides an extensible model that supports an object-tracking service similar to the one that exists in LINQ to SQL. Another feature of LINQExtender is that it does not require you to extend a parser for an expression tree. The existing parser converts an expression tree into a simpler object that describes the query itself. This simplification might not be good for every application, but you will probably encounter many cases in which a simple provider cannot support complex queries just because the service that it wraps has very simple and limited query semantics.

MetaLinq, also called LINQ to Expressions, is a library that allows manipulation of a LINQ query. This library offers an object model through which you can manipulate an expression tree (which could be a query tree) without the limitations imposed by a real expression tree, which is made of immutable objects. The final stage of this manipulation is the creation of an equivalent immutable expression tree that can be used with LINQ.

A useful tool for writing and testing LINQ queries is LINQPad, which is both an interactive editor and an execution environment for LINQ and SQL queries. It supports queries written using LINQ to SQL, LINQ to Objects, and LINQ to XML.

Another interesting tool is LINQ over C# , which provides a parser for Microsoft Visual C# that can be used together with LINQ as a solid base for refactoring code and creating software quality assurance (QA) tools.

Finally, LINQ to Geo is a LINQ implementation for querying geospatial data, and LINQ to Lucene (http://linqtolucene.codeplex.com) supports the Lucene Information Retrieval System, which is a free open-source search engine.

Dot Net 4.0 Parallel Computing

2011-02-20T23:10:00.001+02:00

Data Parallelism

Achieving parallel computing exploits the capability to process large data sets by partitioning them into chunks, each of which gets processed in parallel. Such techniques have existed for a long time in database query processor engines but apply equally well in the context of a general-purpose programming language. This is where TPL’s data parallelism comes in, which can be found in the System.Threading.Tasks.Parallel class.

Parallel For Loops

One first form of data parallelism is exposed by the Parallel.For set of methods, which provide a parallel for loop. The idea of a parallel for loop is to run the iterations of the loop in parallel, followed by a wait operation for all the iterations to complete.

Simple Overloads

The simplest of overloads to For take in three parameters: an inclusive lower bound, an exclusive upper bound, and a delegate representing the loop body. Two families of For loop methods exist, one based on Int32 (C# int) values and another based on Int64 (C# long) values:
static ParallelLoopResult For(int fromInclusive, int toExclusive,Action body);
static ParallelLoopResult For(long fromInclusive, long toExclusive,Action body);

Using ParallelLoopState

A second group of overloads just extends the loop body delegate with an additional parameter of type ParallelLoopState:
static ParallelLoopResult For(int fromInclusive, int toExclusive,Action body);
static ParallelLoopResult For(long fromInclusive, long toExclusive,Action body);
The use case for a ParallelLoopState is to break prematurely from the loop in a variety of ways.
By calling Break, the Parallel.For code ceases to spawn new tasks for the iterations beyond the current point there the break was requested. For example, if Function1 evaluates true in iteration 10, the call to Break will cause no iterations beyond the 10th to get scheduled.

Use of ParallelOptions

Other overloads to Parallel.For take in a ParallelOptions object, which can configure up to three settings:
public class ParallelOptions
{
public CancellationToken CancellationToken { get; set; }
public int MaxDegreeOfParallelism { get; set; }
public TaskScheduler TaskScheduler { get; set; }
}

The first one allows the specification of a cancellation token that can be used to cancel the loop from executing further, causing an OperationCanceledException to be thrown from the Parallel.For code.

Using the MaxDegreeOfParallelism property, the number of parallel workers used to process the loop iterations can be limited. You should exercise caution when using this flag because you might be needlessly reducing the scalability of your application, especially if you use magic constant values here. This flag can be used when you happen to know about competing resources and want to divide parallel resources in one way or another. Typically, such calculations depend on the number of cores, which can be obtained through the System.Environment class.

Finally, the TaskScheduler property can be used to pass in your own scheduler. The MSDN documentation shows how to implement such a beast if you really have to

Parallel Foreach Loops

Just as the Parallel.For method resembles a C# for loop, the Parallel.ForEach method is designed to mirror the C# foreach loop. Given an enumerable sequence, the ForEach method allows for the parallel execution of a loop body for each of the elements in the given sequence.

Most of the concepts discussed in our coverage of For carry over to the ForEach case as well, including the use of ParallelLoopOptions, the ParallelLoopState with Break and Stop methods, and the ParallelLoopResult. Similarly, thread-local state can be associated with the workers that carry out the loop’s work.

The Role of Partitioners

To run operations on the elements of a sequence in parallel, the sequence needs to be partitioned into chunks of work. This is where the concept of partitioners enters the picture. They play a crucial role in the PLINQ implementation.

The idea of a partitioner is to let the workers that execute the loop body process more than just individual elements one at a time. For example, if you have 100 elements and four cores, it makes sense to have each core take care of the work for 25 elements. Such a common partitioning scheme is called range partitioning, where the input sequence size has to be known upfront to create index-based ranges for each worker. This scheme has a disadvantage, though: If one worker completes way before other workers are done with their part of the work, the idle worker cannot steal work.

Another way to partition a sequence is chunk partitioning, where chunks of a given size are processed by workers. This differs from range partitioning in that the split-up of the work is not statically based on the number of workers. For example, given 100 elements and a chunk size of 5, we get 20 units of work. If there are, say, four cores with a worker allocated for each core, they will on average execute five chunks each. This isn’t static allocation of chunks to workers, though; if a worker is presented with a chunk, it can process much faster than another worker can process its chunk, and it can readily move on to the next chunk. Overall, the throughput of the system is higher. Load-balancing partitioning is another name for the use of dynamic chunk-based partitioning.

You can create a partitioner by using the Partitioner.Create factory methods. A set of overloads is based on from and to bounds, combined with range sizes, creating a partitioner that employs range partitioning. Other overloads can take in an array or an IList object, whose length is known immediately. Depending on a Boolean flag named loadBalance, the resulting partitioner uses range partitioning or load-balancing chunk partitioning.

Visual Inheritance In Windows Applications

2009-07-10T11:22:00.004+03:00

As in web application, the concept of Master page was done for implementing some kind of visual inheritance from a page where all child pages have the same look and feel, this is more shown and implemented using Windows application.

Let’s take an example:
Add new project (windows forms application) and a new page and name it for example "Base". put some sort of background image or modify any property for this page (setting the maximize box to false), save and build you application then add new item named inherited form and chose the base form you have already added, and here we go the new page will have the same layout as the base page.

Power of inheritance:
more than this we can use the power of inheritance by defining methods and properties in the main form (Base) that can be override in any child form, let’s consider for example the reset form method that is used to reset all text boxes or dropdown lists or any control say for example the following code:
public virtual void ResetForm ()
{
foreach (Control item in this.Controls)
{
if (item.GetType().Name == "TextBox")
{ item.Text = string.Empty; }
}
}
this is set in the base form and is called in all pages that inherit this form without even defining it and of course it can be overridden

same concept for controls like buttons you can defing you own button that inherits from button control then add some style or even implement some sort of event handling for example:
public class MyButton:System.Windows.Forms.Button
{
protected override void OnMouseHover(EventArgs e)
{
base.OnMouseHover(e);
//change style or do any sort of visual interaction
}
}
then all you have to do just drag and drop it into your form and here you have the same button in all your forms and you can do any change on it , it will be reflected every where.

Design Patterns Applicability

2008-10-21T09:37:00.004+03:00

Creational Patterns

Abstract factory (Kit)

Use the Abstract Factory pattern when

o A system should be independent of how its products are created, composed, and represented.

o A system should be configured with one of multiple families of products.

o A family of related product objects is designed to be used together, and you need to enforce this constraint.

o You want to provide a class library of products, and you want to reveal just their interfaces, not their implementations.

Builder

Use the Builder pattern when

o The algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled.

o The construction process must allow different representations for the object that's constructed.

Factory Method (virtual constructor)

Use the Factory Method pattern when

o A class can't anticipate the class of objects it must create.
o A class wants its subclasses to specify the objects it creates.
o Classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.

Prototype

Use the Prototype pattern when

o a system should be independent of how its products are created, composed, and represented;

and

o when the classes to instantiate are specified at run-time, for example, by dynamic loading;

or

o to avoid building a class hierarchy of factories that parallels the class hierarchy of products; or

o When instances of a class can have one of only a few different combinations of state. It may be more convenient to install a corresponding number of prototypes and clone them rather than instantiating the class manually, each time with the appropriate state.

Singleton

Use the Singleton pattern when

o There must be exactly one instance of a class, and it must be accessible to clients from a well-known access point.
o When the sole instance should be extensible by sub classing, and clients should be able to use an extended instance without modifying their code.

Structural Patterns

Adapter (Wrapper)

Use the Adapter pattern when

o You want to use an existing class, and its interface does not match the one you need.

o You want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces.

o (Object adapter only) you need to use several existing subclasses, but it's impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class.

Bridge (Handle/Body)

Use the Bridge pattern when

o You want to avoid a permanent binding between an abstraction and its implementation. This might be the case, for example, when the implementation must be selected or switched at run-time.

o Both the abstractions and their implementations should be extensible by subclassing. In this case, the Bridge pattern lets you combine the different abstractions and implementations and extend them independently.

o Changes in the implementation of an abstraction should have no impact on clients; that is, their code should not have to be recompiled.

o (C++) you want to hide the implementation of an abstraction completely from clients. In C++ the representation of a class is visible in the class interface.

o You have a proliferation of classes as shown earlier in the first Motivation diagram. Such a class hierarchy indicates the need for splitting an object into two parts. Rumbaugh uses the term "nested generalizations"

o To refer to such class hierarchies.

o You want to share an implementation among multiple objects (perhaps using reference counting), and this fact should be hidden from the client.

Composite

Use the Composite pattern when

o you want to represent part-whole hierarchies of objects.

o you want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly.

Decorator (Wrapper)

Use Decorator

o To add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects.

o For responsibilities that can be withdrawn.

o When extension by subclassing is impractical. Sometimes a large number of independent extensions are

o Possible and would produce an explosion of subclasses to support every combination. Or a class definition

o May be hidden or otherwise unavailable for subclassing.

Façade

Use the Facade pattern when

o You want to provide a simple interface to a complex subsystem. Subsystems often get more complex as they

o Evolve. Most patterns, when applied, result in more and smaller classes. This makes the subsystem more

o Reusable and easier to customize, but it also becomes harder to use for clients that don't need to customize it. A

o Facade can provide a simple default view of the subsystem that is good enough for most clients. Only clients

o Needing more customizability will need to look beyond the facade.

o There are many dependencies between clients and the implementation classes of an abstraction. Introduce a

o facade to decouple the subsystem from clients and other subsystems, thereby promoting subsystem independence and portability.

o You want to layer your subsystems. Use a facade to define an entry point to each subsystem level. If subsystems are dependent, then you can simplify the dependencies between them by making them Communicate with each other solely through their facades.

FlyWeight

The Flyweight pattern's effectiveness depends heavily on how and where it's used. Apply the Flyweight pattern when all of the following are true:

o An application uses a large number of objects.

o Storage costs are high because of the sheer quantity of objects.

o Most object state can be made extrinsic.

o Many groups of objects may be replaced by relatively few shared objects once extrinsic state is removed.

o The application doesn't depend on object identity. Since flyweight objects may be shared, identity tests will return true for conceptually distinct objects.

Proxy (Surrogate)

Proxy is applicable whenever there is a need for a more versatile or sophisticated reference to an object than a simple pointer. Here are several common situations in which the Proxy pattern is applicable:

o A remote proxy provides a local representative for an object in a different address space. Coplien calls this kind of proxy an "Ambassador."

o A virtual proxy creates expensive objects on demand.

o A protection proxy controls access to the original object. Protection proxies are useful when objects should have different access rights. For example, KernelProxies in the Choices operating system provide protected access to operating system objects.

o A smart reference is a replacement for a bare pointer that performs additional actions when an object is accessed. Typical uses include counting the number of references to the real object so that it can be freed automatically when there are no more references (also called smart pointers).

o Loading a persistent object into memory when it's first referenced.

o Checking that the real object is locked before it's accessed to ensure that no other object can change it.

Behavioral Patterns

Chain of responsibility

Use Chain of Responsibility when

o More than one object may handle a request, and the handler isn't known a priori. The handler should be ascertained automatically.

o You want to issue a request to one of several objects without specifying the receiver explicitly the set of objects that can handle a request should be specified dynamically.

Command (Action, Transaction)
Use the Command pattern when

o You want to parameterize objects by an action to perform, as MenuItem objects did above. You can express such parameterization in a procedural language with a callback function, that is, a function that's registered somewhere to be called at a later point. Commands are an object-oriented replacement for callbacks.

o Specify, queue, and execute requests at different times. A Command object can have a lifetime independent of the original request. If the receiver of a request can be represented in an address spaceindependent way, then you can transfer a command object for the request to a different process and fulfill the request there.

o Support undo. The Command's Execute operation can store state for reversing its effects in the command itself. The Command interface must have an added Unexecute operation that reverses the effects of a previous call to Execute. Executed commands are stored in a history list. Unlimited-level undo and redo is achieved by traversing this list backwards and forwards calling Unexecute and Execute, respectively.

o Support logging changes so that they can be reapplied in case of a system crash. By augmenting the Command interface with load and store operations, you can keep a persistent log of changes.

o Recovering from a crash involves reloading logged commands from disk and reexecuting them with the Execute operation.

o Structure a system around high-level operations built on primitives operations. Such a structure is common in information systems that support transactions. A transaction encapsulates a set of changes to data. The Command pattern offers a way to model transactions. Commands have a common interface, letting you invoke all transactions the same way. The pattern also makes it easy to extend the system with new transactions.

Interpreter

Use the Interpreter pattern when there is a language to interpret, and you can represent statements in the language as abstract syntax trees. The Interpreter pattern works best when

o The grammar is simple. For complex grammars, the class hierarchy for the grammar becomes large and unmanageable. Tools such as parser generators are a better alternative in such cases.

o They can interpret expressions without building abstract syntax trees, which can save space and possibly time.

o Efficiency is not a critical concern. The most efficient interpreters are usually not implemented by interpreting parse trees directly but by first translating them into another form. For example, regular expressions are often transformed into state machines. But even then, the translator can be implemented by the Interpreter pattern, so the pattern is still applicable.

Iterator (Cursor)

Use the Iterator pattern

o To access an aggregate object's contents without exposing its internal representation.

o To support multiple traversals of aggregate objects.

o To provide a uniform interface for traversing different aggregate structures (that is, to support polymorphic iteration).

Mediator

Use the Mediator pattern when

o a set of objects communicate in well-defined but complex ways. The resulting interdependencies are unstructured and difficult to understand.

o reusing an object is difficult because it refers to and communicates with many other objects.

o a behavior that's distributed between several classes should be customizable without a lot of subclassing.

Memento (Token)

Use the Memento pattern when

o A snapshot of (some portion of) an object's state must be saved so that it can be restored to that state later, and

o A direct interface to obtaining the state would expose implementation details and break the object's encapsulation.

Observer (Dependents, Publish-Subscribe)

Use the Observer pattern in any of the following situations:

o When an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets you vary and reuse them independently.

o When a change to one object requires changing others, and you don't know how many objects need to be changed.

o When an object should be able to notify other objects without making assumptions about who these objects are. In other words, you don't want these objects tightly coupled.

State (Objects for States)

Use the State pattern in either of the following cases:

o An object's behavior depends on its state, and it must change its behavior at run-time depending on that state.

o Operations have large, multipart conditional statements that depend on the object's state. This state is usually represented by one or more enumerated constants. Often, several operations will contain this same conditional structure. The State pattern puts each branch of the conditional in a separate class. This lets you treat the object's state as an object in its own right that can vary independently from other objects.

Strategy (Policy)

Use the Strategy pattern when

o Many related classes differ only in their behavior. Strategies provide a way to configure a class with one of many behaviors.

o You need different variants of an algorithm. For example, you might define algorithms reflecting different space/time trade-offs. Strategies can be used when these variants are implemented as a class hierarchy of algorithms

o An algorithm uses data that clients shouldn't know about. Use the Strategy pattern to avoid exposing complex, algorithm-specific data structures.

o A class defines many behaviors, and these appear as multiple conditional statements in its operations. Instead of many conditionals, move related conditional branches into their own Strategy class.

Template Method

The Template Method pattern should be used

o To implement the invariant parts of an algorithm once and leave it up to subclasses to implement the behavior that can vary.

o When common behavior among subclasses should be factored and localized in a common class to avoid code duplication. This is a good example of "refactoring to generalize" as described by Opdyke and Johnson. You first identify the differences in the existing code and then separate the differences into new operations. Finally, you replace the differing code with a template method that calls one of these new operations.

o To control subclasses extensions. You can define a template method that calls "hook" operations at specific points, thereby permitting extensions only at those points

Visitor

Use the Visitor pattern when

o An object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes.

o Many distinct and unrelated operations need to be performed on objects in an object structure, and you want to avoid "polluting" their classes with these operations. Visitor lets you keep related operations together by defining them in one class. When the object structure is shared by many applications, use Visitor to put operations in just those applications that need them.

o The classes defining the object structure rarely change, but you often want to define new operations over the structure. Changing the object structure classes requires redefining the interface to all visitors, which is potentially costly. If the object structure classes change often, then it's probably better to define the operations in those classes.

reference:
Design Patterns: Elements of Reusable Object-Oriented Software book

Some Asp.net practices to share

2008-07-15T14:24:00.003+03:00

Greeting developers i have something to share.
while am developing i've discovered some sort of ways that is ment to be an asp.net good practices those methods are:

1-Error handling :
i was fund of all those try catch in all my methods some times am even adding the same call of a method for loging the error and for redirecting to another page or even send email

those were usual and many times i was geeting bored when i was writing the try catch after each new method i write .......

one good prcatice i've found practical is the page error its result was amazing:
first ive created a my own custom page that inherits from system.web.ui.page then i have set all my aspx pages to inherits from this page

next i've implemented the page_error method as follows

Private Sub Page_Error(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Error
'here we can handle page exception logs the errors and redirect
Dim objErr As Exception = Server.GetLastError().GetBaseException()
objErr = Nothing
'of cource u can add here send email or add to event log what ever u want
Me.Response.Redirect("ErrorPage.aspx")
End Sub

and just was it every error generated on the page was logged and redirected to login although in some special cases where i want to handle the code with a different logic i was adding the usual try catch method...

2-SqlDataBase interaction:

for times and times we have worked with ado.net and all its fuctionality and at each class or even on each page we have write the same code defining our connection setting the connection string defining the command to excute nonquerry, scalar or table querry we used our adapter with its select and update commands , we have done the bulk update in the database and all other ado.net and database connection that we are all working with

it seemed non ending and it caused error tracing to be dificult also if u were using in each class the same command you will search where i forgot to invoke the parameter.clear and where the error occure .

i have founded that separating all data access in a class or library would be usefull for example ive created this small class for this idea:

Imports System.Data.SqlClient
Public Class DatabaseCommunication
#Region "Fields"
Private _con As SqlConnection
Private _cmd As SqlCommand
Private _adp As SqlDataAdapter
Private _connectionCounter As Integer
#End Region

#Region "Methods"
Public Sub New(ByVal strConnection As String)
Me._con = New SqlConnection
Me._cmd = New SqlCommand
Me._adp = New SqlDataAdapter
Me._con.ConnectionString = strConnection
Me._connectionCounter = 0
End Sub
Private Sub OpenConnection()
If Me._connectionCounter = 0 AndAlso Me._con.State <> ConnectionState.Open Then Me._con.Open()
Me._connectionCounter += 1
End Sub
Private Sub CloseConnection()
Me._connectionCounter -= 1
If Me._connectionCounter = 0 AndAlso Me._con.State <> ConnectionState.Closed Then Me._con.Close()
End Sub
Public Sub ExecuteNonQuery(ByVal ProcedureName As String, ByVal ProcedureParameters As SqlParameter())
Try
Me._cmd.CommandType = CommandType.StoredProcedure
Me._cmd.CommandText = ProcedureName
If ProcedureParameters.Length > 0 Then
For Each parm As SqlParameter In ProcedureParameters
Me._cmd.Parameters.Add(parm)
Next
End If
Me.OpenConnection()
Me._cmd.ExecuteNonQuery()
Catch ex As Exception
Throw ex
Finally
Me.CloseConnection()
Me._cmd.Parameters.Clear()
End Try
End Sub
Public Function ExecuteScalar(ByVal ProcedureName As String, ByVal ProcedureParameters As SqlParameter()) As Object
Try
Me._cmd.CommandType = CommandType.StoredProcedure
Me._cmd.CommandText = ProcedureName
If ProcedureParameters.Length > 0 Then
For Each parm As SqlParameter In ProcedureParameters
Me._cmd.Parameters.Add(parm)
Next
End If
Me.OpenConnection()
Return Me._cmd.ExecuteScalar()
Catch ex As Exception
Throw ex
Finally
Me.CloseConnection()
Me._cmd.Parameters.Clear()
End Try
End Function
Public Function ExecuteQuery(ByVal ProcedureName As String, ByVal ProcedureParameters As SqlParameter()) As DataTable
Try
Dim dtt As New DataTable
Me._cmd.CommandType = CommandType.StoredProcedure
Me._cmd.CommandText = ProcedureName
If ProcedureParameters.Length > 0 Then
For Each parm As SqlParameter In ProcedureParameters
Me._cmd.Parameters.Add(parm)
Next
End If
Me._adp.SelectCommand = Me._cmd
Me._adp.Fill(dtt)
Return dtt
Catch ex As Exception
Throw ex
Finally
Me._cmd.Parameters.Clear()
End Try
End Function
#End Region
End Class

its small but it will do the desired actions (minor actions) its good to be portable its clean and its easy to trace....

more posts will be more advanced and comming soon thanks all

WCF Windows Communication Foundation

2008-06-05T10:42:00.004+03:00

W C F

Windows Communication Foundation (WCF) is an SDK for developing and deploying services on Windows. WCF provides a runtime environment for your services, enabling you to expose CLR types as services, and to consume other services as CLR types. Although in theory you could build services without WCF, in practice building services is significantly easier with WCF. WCF is Microsoft's implementation of a set of industry standards defining service interactions, type conversion, marshaling, and various protocols' management. Because of that, WCF provides interoperability between services. WCF provides developers with the essential off-the-shelf plumbing required by almost any application, and as such, it greatly increases productivity. The first release of WCF provides many useful facilities for developing services, such as hosting, service instance management, asynchronous calls, reliability, transaction management, disconnected queued calls, and security. WCF also has an elegant extensibility model that you can use to enrich the basic offering. In fact, WCF itself is written using this extensibility model. Most all of the WCF functionality is included in a single assembly called System.ServiceModel.dll in the System.ServiceModel namespace.

WCF Service:

A service is a unit of functionality exposed to the world. In that respect, it is the next evolutionary step in the long journey from functions to objects to components to services. Service-orientation (SO) is an abstract set of principles and best practices for building SO applications. If you are unfamiliar with the principles of service-orientation, A service-oriented application (SOA) aggregates services into a single logical application similar to the way a component-oriented application aggregates components or an object-oriented application aggregates objects

The services can be local or remote, developed by multiple parties using any technology, versioned independently, and even execute on different timelines. Inside a service, you will find concepts such as languages, technologies, platforms, versions, and frameworks, yet between services, only prescribed communication patterns are allowed.
The client of a service is merely the party consuming its functionality. The client can be literally anythinga Windows Forms class, an ASP.NET page, or another service.
Clients and services interact by sending and receiving messages. Messages may transfer directly from client to service or via an intermediary. With WCF, all messages are SOAP messages. Note that the messages are independent of transport protocolsunlike Web services, WCF services may communicate over a variety of transports, not just HTTP. WCF clients may interoperate with non-WCF services, and WCF services can interact with non-WCF clients. That said, typically if you develop both the client and the service, you could construct the application so that both ends require WCF to utilize WCF-specific advantages.
Because the making of the service is opaque from the outside, a WCF service typically exposes metadata describing the available functionality and possible ways of communicating with the service. The metadata is published in a predefined, technology-neutral way, such as using WSDL over HTTP-GET, or an industry standard for metadata exchange. A non-WCF client can import the metadata to its native environment as native types. Similarly, a WCF client can import the metadata of a non-WCF service and consume it as native CLR classes and interfaces.

WCF Adresses:

In WCF, every service is associated with a unique address. The address provides two important elements: the location of the service and the transport protocol or transport schema used to communicate with the service. The location portion of the address indicates the name of the target machine, site, or network; a communication port, pipe, or queue; and an optional specific path or URI. A URI is a Universal Resource Identifier, and can be any unique string, such as the service name or a GUID.
WCF 1.0 supports the following transport schemas:
HTTP
TCP
Peer network
IPC (Inter-Process Communication over named pipes)
MSMQ

WCF Contracts:

In WCF, all services expose contracts. The contract is a platform-neutral and standard way of describing what the service does. WCF defines four types of contracts.

Service contracts
Describe which operations the client can perform on the service.

Data contracts
Define which data types are passed to and from the service. WCF defines implicit contracts for built-in types such as int and string, but you can easily define explicit opt-in data contracts for custom types.

Fault contracts
Define which errors are raised by the service, and how the service handles and propagates errors to its clients.

Message contracts
Allow the service to interact directly with messages. Message contracts can be typed or untyped, and are useful in interoperability cases and when there is an existing message format you have to comply with. As a WCF developer, you should use message contracts only rarely.

WCF Hosting:

The WCF service class cannot exist in a void. Every WCF service must be hosted in a Windows process called the host process. A single host process can host multiple services, and the same service type can be hosted in multiple host processes. WCF makes no demand on whether or not the host process is also the client process. Obviously, having a separate process advocates fault and security isolation. It is also immaterial who provides the process or what kind of a process is involved. The host can be provided by IIS, by the Widows Activation Service (WAS) on Windows Vista, or by the developer as part of the application.

WCF Binding:

There are multiple aspects of communication with any given service, and there are many possible communication patterns: messages can be synchronous request/reply or asynchronous fire-and-forget; messages can be bidirectional; messages can be delivered immediately or queued; and the queues can be durable or volatile. There are many possible transport protocols for the messages, such as HTTP (or HTTPS), TCP, P2P (peer network), IPC (named pipes), or MSMQ. There are a few possible message encoding options: you can chose plain text to enable interoperability, binary encoding to optimize performance, or MTOM (Message Transport Optimization Mechanism) for large payloads. There are a few options for securing messages: you can choose not to secure them at all, to provide transport-level security only, to provide message-level privacy and security, and of course there are numerous ways for authenticating and authorizing the clients. Message delivery might be unreliable or reliable end-to-end across intermediaries and dropped connections, and the messages might be processed in the order they were sent or in the order they were received. Your service might need to interoperate with other services or clients that are only aware of the basic web service protocol, or they may be capable of using the score of WS-* modern protocols such as WS-Security and WS-Atomic Transactions. Your service may need to interoperate with legacy clients over raw MSMQ messages, or you may want to restrict your service to interoperate only with another WCF service or client.
If you start counting all the possible communication and interaction options, the number of permutations is probably in the tens of thousands. Some of those choices may be mutually exclusive, and some may mandate other choices. Clearly, both the client and the service must be aligned on all these options in order to communicate properly. Managing this level of complexity adds no business value to most applications, and yet the productivity and quality implications of making the wrong decisions are severe.
To simplify these choices and make them more manageable, WCF groups together a set of such communication aspects in bindings. A binding is merely a consistent, canned set of choices regarding the transport protocol, message encoding, communication pattern, reliability, security, transaction propagation, and interoperability. Ideally, you would extract all these "plumbing" aspects out of your service code and allow the service to focus solely on the implementation of the business logic. Binding enables you to use the same service logic over drastically different plumbing.
You can use the WCF-provided bindings as is, you can tweak their properties, or you can write your own custom bindings from scratch. The service publishes its choice of binding in its metadata, enabling clients to query for the type and specific properties of the binding because the client must use the exact same binding values as the service. A single service can support multiple bindings on separate addresses.

WCF defines nine standard bindings:

Basic binding
Offered by the BasicHttpBinding class, this is designed to expose a WCF service as a legacy ASMX web service, so that old clients can work with new services. When used by the client, this binding enables new WCF clients to work with old ASMX services.

TCP binding
Offered by the NetTcpBinding class, this uses TCP for cross-machine communication on the intranet. It supports a variety of features, including reliability, transactions, and security, and is optimized for WCF-to-WCF communication. As a result, it requires both the client and the service to use WCF.

Peer network binding
Offered by the NetPeerTcpBinding class, this uses peer networking as a transport. The peer network-enabled client and services all subscribe to the same grid and broadcast messages to it.

IPC binding
Offered by the NetNamedPipeBinding class, this uses named pipes as a transport for same-machine communication. It is the most secure binding since it cannot accept calls from outside the machine and it supports a variety of features similar to the TCP binding.

Web Service (WS) binding
Offered by the WSHttpBinding class, this uses HTTP or HTTPS for transport, and is designed to offer a variety of features such as reliability, transactions, and security over the Internet.

Federated WS binding
Offered by the WSFederationHttpBinding class, this is a specialization of the WS binding, offering support for federated security.

Duplex WS binding
Offered by the WSDualHttpBinding class, this is similar to the WS binding except it also supports bidirectional communication from the service to the client .

MSMQ binding
Offered by the NetMsmqBinding class, this uses MSMQ for transport and is designed to offer support for disconnected queued calls.

MSMQ integration binding
Offered by the MsmqIntegrationBinding class, this converts WCF messages to and from MSMQ messages, and is designed to interoperate with legacy MSMQ clients.

WCF Endpoint:

Every service is associated with an address that defines where the service is, a binding that defines how to communicate with the service, and a contract that defines what the service does. This triumvirate governing the service is easy to remember as the ABC of the service. WCF formalizes this relationship in the form of an endpoint. The endpoint is the fusion of the address, contract, and binding. Every endpoint must have all three elements, and the host exposes the endpoint. Logically, the endpoint is the service's interface, and is analogous to a CLR or COM interface.
Every service must expose at least one business endpoint and each endpoint has exactly one contract. All endpoints on a service have unique addresses, and a single service can expose multiple endpoints. These endpoints can use the same or different bindings and can expose the same or different contracts. There is absolutely no relationship between the various endpoints a service provides.
It is important to point out that nothing in the service code pertains to its endpoints and they are always external to the service code. You can configure endpoints either administratively using a config file or programmatically.

This ends this post as an introduction to WCF later post will include more info and more advanced samples. Please free to comment .

Active Directory Membership Provider

2007-09-27T15:28:00.002+03:00

The ActiveDirectoryMembershipProvider supports almost the entire set of functionality
defined by the Membership API. You can create and manage users with either Active Directory
(AD) or the standalone directory product Active Directory Application Mode (ADAM).
Furthermore, you can use the provider in both ASP.NET and non-ASP.NET applications. Because
the ActiveDirectoryMembershipProvider closely mirrors the SqlMembershipProvider in
terms of functionality, the interesting parts of ActiveDirectoryMembershipProvider are how
the provider works with the directory server and how certain Membership operations are mapped
to AD and ADAM.

Provider Configuration

If you configure the provider with the minimum number of required configuration attributes, most of its
functionality will work against existing AD installations. About all you need to get up and running is a
provider definition and a valid connection string:

It is pretty much guaranteed that for production applications, though, you will need to delve a little
more deeply into the provider’s configuration. The section “Working with Active Directory” walks you
through a number of the common configuration tasks for setting up the provider.

Directory Connection Settings

As with SQL provider, you need to at least supply a connection string so that the provider knows where
it should read and write data. However, unlike SQL Server connection strings, there is no such thing as
specifying explicit connection credentials inside of the connection string. Also connection security settings
cannot be supplied inside of an LDAP connection string. As a result, the provider supports a number

The connection string that you use for the provider is placed in the section.
The provider references the connection string via the connectionStringName attribute. The connection
string that you create supports a number of different formats, depending on whether you are connecting
to AD or ADAM. For example, if you are running in a domain called foo.org and you have an AD
domain controller called dcserver, the most prevalent forms of the connection string when connecting
to AD look like:
❑ LDAP://foo.org
❑ LDAP://dcserver.foo.org
❑ LDAP://foo.org/OU=SomeOU,DC=foo, DC=org
❑ LDAP://dcserver.foo.org/OU=SomeOU,DC=foo,DC=org
However, if you are connecting to an ADAM server, you always need to have an application partition
defined. Assuming that you have an ADAM server called adambox in the foo.org DNS namespace, you
could use connection strings like:
❑ LDAP://adambox.foo.org/O=myorg,DC=foo,DC=org
❑ LDAP://adambox.foo.org/OU=SomeOU,O=myorg,DC=foo,DC=org
Unlike AD, ADAM servers can be listening on nondefault LDAP ports. If you install ADAM to listen on
other ports, then the connection string can look like:
❑ LDAP://adambox.foo.org:50001/O=myorg,DC=foo,DC=org
❑ LDAP://adambox.foo.org:50001/OU=SomeOU,O=myorg,DC=foo,DC=org
If you do install ADAM on a nondefault port, and you plan on using secure connectivity to the ADAM
server, you must make sure that SSL support has been configured properly on the ADAM server and on
each of the machines that needs to connect to the ADAM server. If you don’t change the default port settings
for ADAM, then SSL traffic by default occurs on port 636 (unsecured traffic occurs on port 389 by
default). If your ADAM server uses these default ports, then you don’t need to specify a port number in
the connection string.
Because both AD and ADAM can replicate changes across servers, the type of connection strings that
you use will have an effect on when the provider sees changes made on other machines. For example, if
you use an AD connection string that points only at a domain, it is possible that across a web farm different
web servers will end up connecting to different domain controllers. This can lead to odd behavior
where changes made to a MembershipUser on one server don’t show up immediately on other servers
in your farm. Unfortunately, there isn’t anything the provider itself can do to mitigate the inherent
latency of AD’s multimaster behavior. However, you can at least use connection strings that explicitly
specify a server—in this case all provider instances that are pointed at the same server will see a consistent
set of information.
One very important aspect of connecting to the directory server is connection security. From the sample
connection strings, you saw that there is no indication of the secured state of the connection. You request
security for the connection to the directory server via the connectionProtection provider configuration
attribute. This attribute can be set to either None or Secure. By default, if you do not specify the
attribute in your provider’s configuration, the provider will default to Secure.

The reason that the attribute has only one of two settings is that attempting to expose the vagaries of
negotiating secure connections with a directory server can quickly become very complicated. So rather
than leaving it up to you to get things working, the provider simplifies the issue into a simple binary
decision. Either you want connection security automatically established, or you don’t. Of course, there is
a bit more complexity than that occurring underneath the hood. There are a number of mix-and-match
combinations you can use with connectionProtection and the credentials used by the provider when
connecting to the directory, though only a subset of settings really make sense.

❑ connectionProtection=None for AD—This is not a combination you should ever use. In
AD environments, any operations that set or change passwords must be done over secure connections,
so with a setting of None, the provider will always fail when it attempts things like
ChangePassword or ResetPassword. Also, you need to always use explicit connection credentials
with this setting. Because AD has built-in support for automatically securing connections
there isn’t much reason for ever using None in an AD environment.

❑ connectionProtection=None for ADAM—You may find yourself using this combination in
a development environment where you don’t have SSL certificates set up for your ADAM
server and client machines. As with AD, you will need to configure the connection credentials
explicitly to use the None setting. Note that for ADAM this means that you will be limited to
using only ADAM user principals for the explicit credentials; domain credentials cannot be
explicitly specified for ADAM when connectionProtection is set to None. Unlike AD,
though, you can manually configure ADAM to allow password changes and resets to occur over
unsecured connections. The section on “Using ADAM” later in the chapter shows you how to
do this. Note though that I would not recommend using None in a production setting with
ADAM; it only makes sense as a convenience early on during a development cycle. Even for
development scenarios, at some point you should get SSL set up so that you are coding in an
environment that more closely matches your deployment environment.

❑ connectionProtection=Secure for AD—This is the default when connecting to an AD
server, and it is the setting that you should use for most cases when working with AD.
Internally, the provider will first make a check to see if SSL is supported on the directory server.
If it is, all LDAP traffic will flow over Active Directory’s SSL port (that is, port 636). If SSL is not
configured for AD, which is normally the case for at least intranet directory servers, then the
provider will fall back and use signing and sealing for all LDAP traffic. If you have configured
SSL in an extranet directory environment for example, then the provider will make use of SSL
in preference to signing and sealing. Because the provider internally makes use of the Active
Directory Services Interface (ADSI) API, it turns out that setting up SSL for AD environments
gives the best performance when using the provider to connect securely to AD. Using SSL
reduces the number of network connections that ADSI will open on behalf of the provider when
making secure connections to AD.

❑ connectionProtection=Secure for ADAM—This is the default when connecting to an
ADAM server. As noted earlier, this setting will not work unless you have explicitly set up SSL
on your ADAM server as well as on all machines that need to communicate with that server.
The reason for this restriction is that unlike when connecting to AD, the provider only supports
the use of SSL for securing network traffic with the ADAM server. Even if the ADAM instance is
running on a server joined to a domain, the provider will not attempt to use signing and sealing.
When you set connectionProtection to Secure, you can find out the actual connection security that
was chosen at runtime by querying the provider’s CurrentConnectionProtection property. This
property returns a value from the System.Web.Security.ActiveDirectoryConnectionProtection
enumeration that will tell you if SSL or signing and sealing were chosen.
of additional configuration settings.

The last set of connection information that you can configure in the provider’s element is explicit
connection credentials. The configuration attributes connectionUsername and connectionPassword
can be used to explicitly specify the username and password to use when connecting to the directory
server. If you don’t explicitly specify values for these settings the provider attempts to connect to the directory
using either the process credentials from the IIS6 worker process, or the application impersonation
credentials if application impersonation is in effect. If you explicitly specify the username and password,
make sure to use protected configuration (discussed in Chapter 4) so that the credentials are not stored in
cleartext on your production servers.
The format of the username differs, depending on whether you are connecting to AD or ADAM:

❑ AD—You can specify the username in any format that is supported by Windows. The two most
common username formats are the NT4-style format of DOMAIN\USERNAME and the user principal
name format of username@domain.name.

❑ ADAM—If you are connecting to an ADAM server with connectionProtection set to Secure,
then you can explicitly specify either an ADAM user principal or a domain user account. For a
protection setting of None though, only an ADAM user principal can be specified. An ADAM
principal looks something like CN=Username,OU=AccountOU,O=MyOrganization,DC=corsair,
DC=com. In the section on “Using ADAM,” there is a walkthrough of how to use an
ADAM user principal when connecting to an ADAM server.

Check the new post on Active Directory Membership Provider

JSON

2007-09-21T17:16:00.002+03:00

Overview:

With the still-rising popularity of web services, XML has practically become the de facto standard for data transmission. However, XML is not without its detractors. For example, some consider it to be overly verbose for data transmission purposes, necessitating many more bytes of information to be sent across the Internet to accomplish what could have been done in a much smaller form. To take this into consideration, new forms of XML compression and even entire new XML formats, such as Binary XML, have been developed. All these solutions work on extending or adding on to XML, making backwards compatibility an issue. Douglas Crockford, a long-time software engineer, proposed a new data format built on JavaScript called JavaScript Object Notation (JSON).
Up until this point, you've used either plain text or XML to transmit data back and forth to the server. This chapter introduces the use of JSON in Ajax communication as an alternative to these more traditional data formats.

What Is JSON?

JSON is a very lightweight data format based on a subset of the JavaScript syntax, namely array and object literals. Because it uses JavaScript syntax, JSON definitions can be included within JavaScript files and accessed without the extra parsing that comes along with XML-based languages. But before you can use JSON, it's important to understand the specific JavaScript syntax for array and object literals.

JSON versus XML

One of the advantages of JSON over XML is that it's more compact. XML is considered by some to be overly verbose for its purpose. But what does this mean exactly? Consider the following XML data:

Michael Smith
99.5
17
true

Steve Johnson
34.87
17
false

Rebecca Young
89.6
18
true

This example contains information about three students in a class. Right away, there is some XML information that isn't entirely necessary: the and elements.
These elements help to define the overall structure and meaning of the information, but the actual information you're interested in is the students and their information. Plus, for each piece of information about the students, the name of the information is repeated twice, although the actual data is repeated only once (for example, "name" appears both in and . Consider the same information formatted as JSON:
{ "classinfo" :
{
"students" : [
{
"name" : "Michael Smith",
"average" : 99.5,
"age" : 17,
"graduating" : true
},
{
"name" : "Steve Johnson",
"average" : 34.87,
"age" : 17,
"graduating" : false
},
{
"name" : "Rebecca Young",
"average" : 89.6,
"age" : 18,
"graduating" : true
}
]
}
}
As you can see, a lot of the superfluous information isn't present. Since closing tags aren't necessary to match opening tags, it greatly reduces the number of bytes needed to transmit the same information. Not including spaces, the JSON data is 224 bytes, whereas the comparable XML data is 365 bytes, saving more than 100 bytes. (This is why Crockford, JSON's creator, calls it the "fat free alternative to XML.")
The disadvantage to JSON-formatted data as compared to XML is that it's less readable to the layperson. Because XML is verbose, it's fairly easy to understand what data is being represented. JSON, with its shorthand notation, can be difficult to decipher using the naked eye. Of course, an argument can be made that data exchange formats should never be viewed with the naked eye. If you're using tools to create and parse the data being passed back and forth, then there is really no reason to have the data be human readable. But this begs the question: Are there any JSON tools available? The answer is yes.