Application Framework Development
We are discussing the development of a Microsoft-Application-Block style framework that would offer the following services:
1. Persistence
2. Caching
3. Lookup Management
4. Workflow
5. Multi-threaded tasks
6. Code Generation (for sprocs, persistence classes, lookup classes)
7. Configuration Management for connection strings
8. Exception Management, Logging Tracing
9. Security (Authetication, Authorization)
10. Events and Asynchronous wrappers
The project is ambitious and we have a few models to choose from. I will be posting on this (hopefully) regularly from now on.
The purpose of this framework is to help quickly develop, intranet web applications - such as an internal Library Management App, a Resume Management App, a Timesheet Tracker.
We have not yet decided if the framework will be open source - we will cross that bridge when it comes. Let us see if we complete it first.
The first decision we made was that we would use .NET because all of us are familiar with it. But, we also decided we will keep the patterns documented so that we can port to Java at some point.
It will use .NET 2.0 and hence features such as Generics will be used. It will not use .NET 3.0 for Workflow Management - for now. I am leaving that option open. We will use patterns from the Workflow Foundation.
The applications that will be built on top of this framework can be web or windows based. I like service based applications - because they are easy to switch between using Ajax or Flex for front end. We do not plan to build our own UI controls.
C# is the language of our choice.
NUnit is our choice for a testing tool.
Our primary target database server will be SqlServer 2005. But, I want to design the framework with MySql support possible in the future. This is not very tough to do; the MS Data Access Application Block has a nice set of patterns for such database agnosticism.
It is always a challenge in these kind of frameworks to decide which areas should be delegated to third party providers (in open source). One example is the Logging framework - Log4net is an obvious choice. It supports logging to the file system, event log or to the database. It supports different levels of configuration based logging. The only issue I have with third party software, particularly open source, is that they do not upgrade to later versions at your convenience. I am almost convinced we should use Log4net. It is also an issue of complexity though. It is likely we will standardize on a database log. We know that database server will be Sql Server. Do we really need an "appender" based, extensible system such as Log4net provides?
Other than Log4net, the other area that may need a third party software (although not necessarily free) is Code Generation. I will write about this in detail in the next post.
We plan to follow Microsoft standard naming conventions.
Comments? What comments?
1. Persistence
2. Caching
3. Lookup Management
4. Workflow
5. Multi-threaded tasks
6. Code Generation (for sprocs, persistence classes, lookup classes)
7. Configuration Management for connection strings
8. Exception Management, Logging Tracing
9. Security (Authetication, Authorization)
10. Events and Asynchronous wrappers
The project is ambitious and we have a few models to choose from. I will be posting on this (hopefully) regularly from now on.
The purpose of this framework is to help quickly develop, intranet web applications - such as an internal Library Management App, a Resume Management App, a Timesheet Tracker.
We have not yet decided if the framework will be open source - we will cross that bridge when it comes. Let us see if we complete it first.
The first decision we made was that we would use .NET because all of us are familiar with it. But, we also decided we will keep the patterns documented so that we can port to Java at some point.
It will use .NET 2.0 and hence features such as Generics will be used. It will not use .NET 3.0 for Workflow Management - for now. I am leaving that option open. We will use patterns from the Workflow Foundation.
The applications that will be built on top of this framework can be web or windows based. I like service based applications - because they are easy to switch between using Ajax or Flex for front end. We do not plan to build our own UI controls.
C# is the language of our choice.
NUnit is our choice for a testing tool.
Our primary target database server will be SqlServer 2005. But, I want to design the framework with MySql support possible in the future. This is not very tough to do; the MS Data Access Application Block has a nice set of patterns for such database agnosticism.
It is always a challenge in these kind of frameworks to decide which areas should be delegated to third party providers (in open source). One example is the Logging framework - Log4net is an obvious choice. It supports logging to the file system, event log or to the database. It supports different levels of configuration based logging. The only issue I have with third party software, particularly open source, is that they do not upgrade to later versions at your convenience. I am almost convinced we should use Log4net. It is also an issue of complexity though. It is likely we will standardize on a database log. We know that database server will be Sql Server. Do we really need an "appender" based, extensible system such as Log4net provides?
Other than Log4net, the other area that may need a third party software (although not necessarily free) is Code Generation. I will write about this in detail in the next post.
We plan to follow Microsoft standard naming conventions.
Comments? What comments?
Labels: .NET, Application framework
posted by Ramiah Ariya at
4:59 AM
0 Comments:
Post a Comment
<< Home