dnp.Framework code released!

May 21, 2009 22:25 by garrymc

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...
    Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList

Currently rated 2.7 by 10 people

  • Currently 2.7/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Modeling many-to-one (M:1) entity relationships Part II

June 25, 2008 19:00 by garrymc

This is the second part of the series which discusses the issues around modeling M:1 (many-to-one) relationships. If you've not read the first part, then its advisable that you read that first before continuing with this part. To keep up to date with this and other blog's you might consider registering with the RSS feed.

Part I: The Problem

Part III: BusinessKey as a value type

Suggested Solution

Having covered the issues with M:1 relationships and the three different types I'll now present a potential solution which provides the necessary foreign key information, but in a more domain model fashion. I'll also point out yet another issue with the original logical model when it comes to actually using it, which I'll also offer up a solution for. More...

Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList

Currently rated 2.3 by 6 people

  • Currently 2.333333/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Modeling many-to-one (M:1) entity relationships Part I

June 22, 2008 13:06 by garrymc

Designing a domain model can be a tough job and if you're lucky enough to start from scratch then it becomes even tougher once you apply it to the physical database model. Over the next few posts I' like to discuss the issues we encounter when modeling this relationship type, examine the way its 'normally' done and then present an alternative that I believe presents a more domain model centric view of the world. The series will be broken up into the following sections, with this being the first. To keep up to date with this and other blog's you might consider registering with the RSS feed.

Part I: The Problem

Part II: Suggested Solution

Part III: BusinessKey as a value type

The main issue when designing a domain model is that they don't have these oddities called foreign keys, as the relationships are known by association. However, once you turn your domain model into a database schema we have to start adding all these extra keys, which get worse when you have a M:M (many-to-many) relationship! In this post I'd like to discuss how we normally model the M:1 (many-to-one) relationship and its pitfalls. More...

Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList

Currently rated 2.5 by 2 people

  • Currently 2.5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Database Explorer API beta released

March 17, 2008 17:10 by garrymc

For anyone that's read my blog entries you've seen me make mention to a framework that I've been working on. Well today marks the release of the first beta of part of that framework. The Database Explorer API, is a database schema API that is designed to make accessing database schema information easy and intuitive. More...

Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList

Currently rated 3.0 by 7 people

  • Currently 3/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Did you forget something when you deployed your ASP.NET App?

March 15, 2008 04:54 by garrymc

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.

   1: <system.web>
   2:   <compilation debug="false" />
   3: </system.web>

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!

kick it on DotNetKicks.com
Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList

Currently rated 2.5 by 13 people

  • Currently 2.538461/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5