This project is read-only.

Common Library

It provides various common interfaces/utilities required in RapidWebDev even directly used to build your applications. They’re small but quite useful and helpful. The main features include Cache, Dynamic Class, Data, Globalization, Validation, Web (restful web services support and client script management), Logging, Spring Context and common methods. The article below introduces these functionalities in high level.

Cache

Cache in common library is only an adapter to isolate developers from a special cache implementation. It provides an interface ICache having basic cache access signature as Get, Add and Remove. Developers should interact with cache by the instance resolved from Spring IoC which the cache implementation is configured in. With this design, it’s quite easy to switch the implementation at runtime by needs. Even you can implement a Non-cache adapter so that you can turn off the caching for any purposes at a time. By default, there has http runtime cache adapter.


Dynamic Class Generator

It’s used to create dynamic classes and objects with WCF data contract marked and full serialization support at runtime. We store dynamic properties with property values into a Dictionary for a product entity. We expect the dynamic properties looking no difference as hardwired properties when we response product entities to customers in either XML or JSON format. But we cannot resolve response data by .NET serialization to product entities. In this case, we can use Dynamic Class Generator to create dynamic classes from both hardwired properties or dynamic properties of product entities at runtime. Then we only need to serialize dynamic objects into XML or JSON format by .NET serializers like JavaScriptSerializer, DataContractSerializer etc.

TransactionScope without MSDTC for Linq2SQL DataContext

When we're designing independent APIs, System.Transactions.TransactionScope makes it easy to keep either a single API in a transaction or a combination of multiple APIs in a transaction. But in SQL2005 or before, the transaction by System.Transactions.TransactionScope is escalated to MSDTC if there are multiple db connections even db connection status change. The MSDTC escalation decreases database access performance seriously. And we don't consider to design API depending on external Linq2SQL data contexts, db connections or transactions. So, we write a new TransactionScope in common library working the same as System.Transactions.TransactionScope but supports ADO.NET transaction across different Linq2SQL data contexts using the same database without MSDTC dependency. Besides, it's integrated with the cache infrastructure which supports consistency between cache and database transaction.

Globalization and Localization

The globalization utility integrates with .NET globalization solution which is used to replace globalization markup in any text. The markup format follows “$Namespace.ClassName.PropertyName, AssemblyName$” however the PropertyName is internal or private in an assembly. And the localization utility is used to convert DateTime value by custom algorithms which are configurable in Spring.NET IOC, e.g. localization by web client timezone.

Validation Framework

See detail introduction here.

The trouble issue in validation I have is how to collect all invalid information and provide an error message to users with all of them at a time. This works hard especially when we’re API oriented programming. There is validation in each independent API. The API may throw an exception or return an object to indicate error messages. In a series of API execution, we’re hard to combine all errors or decide whether to stop executing when an API returns an exception.

So we have ValidationScope in RapidWebDev infrastructure. ValidationScope supports nest likes TransactionScope. When you have an error message, you can add it into validation scope instead of throwing or returning an exception. When the validation scope is disposing, it throws an exception depends on whether there has errors logged and configuration parameters. The nested validation scope doesn’t throw an exception although there has errors logged in the scope if the validation scope is created by default parameters.

using (ValidationScope validationScopeOuter = new ValidationScope())
{
    validationScopeOuter.Error(“Error message 1.”);
    using (ValidationScope validationScopeInner = new ValidationScope())
    {
        validationScopeInner.Error(“Error message 2.”);
        validationScopeInner.Error(“Error message 3.”);
    }
}

Seeing code snippet above, a validation exception will be thrown when outer validation scope is disposing with all three error messages. The internal validation scope block also can be wrapped in a standalone API and the API is called here.

Besides, you also can explicitly call method Throw of validation scope to force throwing an exception if there has error messages. And the thrown exception can be customized.

Client Script Registration

Client script registration helps to register javascript code block or file references to client browsers without taking care whether the request is asynchronous or in postback. And client script registration also supports to register scripts being executed only when the document inner of client browser is on ready.

Others

Additionally, Common provides other useful interfaces and common utilities for almost applications.

Application Context

The interface IApplicationContext is used to isolate logic applications in RapidWebDev. It’s very important for SAAS applications. Developers can resolve the instance from Spring.NET. With this interface, developers can know which application is in current execution context and they can access Session and Temporary Variables (By Request) without coupling to ASP.NET HttpContext.Current.Session and HttpContext.Current.Items. Finally developers also can get basic authentication from this interface.

IApplicationContext applicationContext = SpringContext.Current.GetObject<IApplicationContext>();
// Get current application id by appicationContext.ApplicationId
// Get current authentication by appicationContext.Identity

Spring Context

It’s used to resolve the instance of type Spring.Context.IApplicationContext without interacting with Spring.NET factories. Developers only need to use SpringContext.Current to get the instance of type Spring.Context.IApplicationContext. Besides, there also adds some extension methods onto the type Spring.Context.IApplicationContext to support generic ways.

IApplicationContext applicationContext = SpringContext.Current.GetObject<IApplicationContext>();
// Here gets an instance implemented IApplicationContext from Spring.NET IOC 
// without explicitly specifying object id while resolving.

Logger

The factory is used to resolve the instance of type Common.Logging.ILog to log messages. Common Logging is an open source project which integrates all famous logging solutions and provides façade APIs to log messages. The typical logging solutions like log4net, MS Enterprise Logging and NLog etc.

Common Methods

It’s a series of useful and helpful common methods. Please see the API Documentation or source code for detail.

Last edited Feb 3, 2010 at 3:30 PM by eungeliu, version 11

Comments

No comments yet.