Introduction
DotNetX (DotNet eXtended framework) is a group of libraries that helps common tasks on software developing. This framework includes ways of dynamically managing database cache or connecting to different data providers without changing your code, as well as other day to day tasks.
The packages
DotNetX.Configuration
This namespace includes a AppSettings helper class and a CommandLineArguments helper class.
DotNetX.Diagnostics
It includes a Trace class that encapsulates System.Diagnostics.Trace and also web tracing. It also includes IPerformanceTest interface that should be implemented by performance tests (this feature will be released in the next build).
DotNetX.Reflection
It includes reflection helper classes. At this moment, only an Assembly class is provided. Future builds will include more functionality.
DotNetX.RemotablePlugin
This is the most important feature of the framework. The framework created an evolution of the factory pattern to what we call Remotable Plugin Pattern (RPP - sorry.. but giving names is not one of my qualities...). The Remotable Plugin Pattern allows the final developer to customize the implementation and also its host model, like, for example, to host the object on a remote machine using remoting.
Please note that this is a very immature pattern and some stabilizing should be made before fully using this on production environments. One of the issues to care is security since there isn't any authentication between the consumer and the implementation.
This namespace includes FactoryBase, from which RPP objects should derive.
DotNetX.Caching
It includes a cache factory based on configuration settings as well as two implementations of ICacheProvider, like WebStorage that simply uses the HttpRuntime cache, and WeakReferenceWebStorage that inherits WebStorage but uses a weak reference to the object so GC can collect the object if resources are needed.
The cache factory class (CacheFactory) derives from the Remotable Plugin Pattern (RPP), allowing, for example, to host the cache on another machine using .NET Remoting, or even sharing cache between different applications, using a common repository.
DotNetX.Context
It includes context functionalities, encapsulating HttpContext and call context. It also uses a factory so you can customize your final implementation, and also respects RPP.
DotNetX.Security.Cryptography
It includes a Symmetric factory class implementing RPP. It also includes a Symmetric base class from which symmetric algorithm implementations should derive. This namespace also includes some known symmetric algorithm implementations.
DotNetX.Text
Text manipulation classes.
DotNetX.Data
This namespace includes a class (CommandHelper) that helps to execute commands against a database. One of the main features of these classes is the facto of being completely independent of the data provider, since it only knows IDb interfaces, and the final implementation can also be configured in app.config. This means that you can connect to the database using the best data provider and at the same time have your code completely independent of it, by simply consuming this independent class. On another way, if you need to directly consume IDb objects like IDbConnection or IDbCommand, a factory is provided in ProviderFactory class, meaning that your code continues to be independent.
This namespace also includes a very important object called ConnectionContext that holds a connection context to execute database commands. This object can be used to start transactions and pass transactions between components.
DotNetX.TableReflection
Table reflection is a pattern where you create your data access components reflecting your database. This pattern allows the powerful fact of only going to the database when necessary, because all the calls to the same table are done through a single object, and that object can control when to expire or use cache instead of going to the database. Further details about this functionality will be released in future documentation and builds, since this functionality can be more powerful with code generation being released in the next build. If you want to know more before the documentation, you can take a look at nUnit projects in the source code, where some examples are made.
Please note that to use this pattern you have to derive from EntityBase and document your class using the attributes in Attributes namespace.
A bind helper class is also available allowing user interface to be dynamically generated when using IEntity classes.
Final notes
This is the first release of DotNetX, and so please understand that some immature code may appear.
The next release will include code generation libraries and tools and the ability to write your own code generation pattern.
For further details of latest builds, please visit http://www.dotnetx.org/ or http://workspaces.gotdotnet.com/dotnetx.
