In an effort to start getting more of the code I’ve been working on out in the public domain, I’ve finally released all the code for the dnp.Framework on CodePlex. While its not all complete, most of the code is quite stable and can be used now!
Some of the major components that are included in the framework include:
- Database Explorer API: An object oriented database schema API which is ideal for anyone wanting to do code generation. Its based on the provider pattern, so while it currently only supports SQL Server 2005+ its fairly easy to create a new provider for any system. This is stable enough for production use and has an extensive set of unit tests.
- Data Provider: This is a database agnostic API which is fairly similar to the one in the enterprise library except it doesn’t support datasets and the like. Its also has little overhead. This was designed before the Enterprise Library had a decent model, and it has also been used on mobile devices with the compact framework.
- DomainModeller: An abstract domain model view of a database schema (extends Database Explorer API). This API is most useful to creating scripts for code generation, where you can concentrate on domain concepts such as base classes, derived classes, namespaces and relationships etc, rather than database concepts. Using this API for code generation can significantly reduce the amount of code typically required.
- ServiceModel: This project is still under development, but aims to provide the first ‘Model’ that extends the Domain Modeller to define a Service based Application framework. The ServiceModel acts as the abstract API for the final code generation scripts which are currently written using CodeSmith. The scripts currently have good support for the data access layer (repository), service layer (business logic) and entities (using design discussed here). More...
While I don't normally get involved with deploying web applications (we normally have 'people' for that) however I did have to deploy the application you're using now. Which brings me to the blog post I recently found which discusses the top 10 best practices for ASP.NET which I've linked to on my toolbox page. The main one that concerned was of concern to me was forgetting to switch off debug mode.
2: <compilation debug="false" />
This setting appears to have a large impact on production web sites so I'd check out the detail in the this post to get all the details. Also you might want to check the config files of the production apps you work on or blog if you host your own; lets just say we may need to update a few of ours!
This article was originally published in the April 2003 issue of Visual Studio Magazine. Their online version has been archived, so it has been reproduced here. The articles code requires updating for .NET 2.0 which will be the subject of a future post.
ASP.NET has brought about a huge change in how we as developers think about designing a web site. We all know that ASP.NET now gives us the opportunity to create reusable custom controls which we can drag and drop onto our pages, which can even remember the information entered between postbacks, using the viewstate mechanism built into ASP.NET. This has proven to be a huge advantage in designing our pages, by allowing us to bring our more traditional programming model to the Web for the first time. ASP.NET also allows us to add these same controls dynamically at runtime. More...
In many application be they web or otherwise it can be important to secure parts of the configuration files incase the file is compromised by a hacker or you simply don't want anyone to know what the true values are. It turns out that this is fairly easy to do using the ASP.NET IIS Registration Tool (Aspnet_regiis.exe) (obvious right?). To illustrate the point I'll show you a typical config file and what's required to encrypt parts of it. More...