EditCode Generation
CodeSmith is a template driven code generator that can be used with C# or Visual Basic .NET and can generate any language or text you wish. BE Careful! Because of it's architecture, you can only use it with ASP.Net Projects!. As developers, several aspects of our craft have come full circle, where code generation has matured to a point where it has become a necessity and preferred practice. Code generation helps protect against the mistakes of man. Once you've solidified your code generation process, the chance of creating bugs in a certain piece of code drop dramatically. And should a bug appear, you simply have to change your templates and it will correct itself accross the entire application. Much better than the previous way of relying on yourself to find all instances of a scenario where the behavior caused by the bug was failing. Not to take anything away from the extremely powerful refactoring tools today, they help us out tremendously, but they are very limited when it comes down to actually changing behavior, where code generation is much better suited. A CodeSmith template allows you to define properties that can be used along with rich meta-data to create the most powerful of templates, and the best part, it looks and acts just like Asp.net. Your options for a rich meta data include, RDBMS, XML, .net Types, or easily create your own.
Edit.netTiers, An Introduction
.netTiers is a library of open source CodeSmith templates written in C#. The intention of the templates is to assist developers by eliminating repetitive, mundane coding, while at the same time providing a full-fledged framework that allows those developers to get started working on what matters the most to their applications such as the presentation layer, business rules, workflow, and application health. Consider .netTiers an application block, only specialized to your domain model, and the growth from within the product will more likely be vertically more than horizontally. Meaning, future versions will be focusing on providing more things out of the box which will assist you in your everyday development tasks.
The templates effectively build a set of object-relational domain objects for an existing database based off of Model Driven Design (MDD). MDD essentially is the concept where a predesigned model is used to generate your application. MDD was made famous by many UML modelers, such as Rational Rose, etc. However, with the advent of CodeSmith's rich set meta-data via it's SchemaExplorer, MDD has been particularly easy to adopt for .netTiers through the familiar data model. It's .netTiers' responsibility to have the ability to take a good database design and yield a wonderful generated domain for your codebase. Since the majority of business applications revolve around data, .netTiers offers up the ability to work with your data in the easiest way possible as soon as possible.
EditCurrent .netTiers Feature Set
This is a generalized list of features that .netTiers provides. You can find more information on these topics within the documentation.
- Generates a fully compilable solution along with separate projects and framework tiers for your application. You can start working on an application immediately after generating.
- Creates a full suite of stored procedures that are specialized towards your domain. This code can run inline, as parameterized SQL as well and does not have to be used as procedures.
- Automatically generates entity objects and their relationship objects as a domain based on the tables of your database.
- Advanced Entity Validation Rule Engine, which can use any of the pre-created or use delegates for any custom rules.
- Classes include both partial classes and concrete classes throughout so that you can customize logic that will not be overwritten.
- Uses a custom generic List for collections that supports all .NET ComponentModel interfaces and more, and are Bindable, Sortable, and Filterable.
- Creates a full website project, already pre-configured and ready to begin coding against your data immediately.
- Creates a full set of administration web controls, that serves as a basic yet fully functional web administration console for database.
- Creates a full set of typed DataSource controls for your entire API with design time support, they are similar to the ObjectDataSource, only these are full featured and are actually developer friendly.
- Creates a full Web service API for your domain, perfect for a .NET WinForms or smart client application and is simple to configure.
- Creates a full suite of unit tests for the data providers and provides about 50% coverage. These tests are for NUnit or Visual Studio Team System.
- Code is fully commented throughout and ready for your documentation needs. Also follows Microsoft naming guidelines throughout.
- Any code placed in a special folder in any of the projects, which by default is called App_Code, will automatically be included in the generated project.
- The Data API consists of query support by Primary Key, Foreign Key, Indexes, ManyToMany join relationships, All, Paged Select with Filter, and Find, along with database write methods such as Insert/Update/Delete.
- You can create your own custom stored procedures for your entities and .netTiers will generate a wrapper and all the plumbing for that procedure. This enables you to have your own logic within the .netTiers API.
- And much, much, more. Honest...
Edit.netTiers Architecture
 Architecture |
This data tiers concept is composed of custom business entities components (the data itself) and data access logic components (the persistence logic).
This design is inspired from the Microsoft patterns & practices guide:
Designing Data Tier Components and Passing Data Through TiersEditEnterprise Library Application Blocks:
As you can probably tell by now, .netTiers is meant to assist you to do things faster for your all around applications, and not just data access. You might've heard the mantra, "work smarter not harder". Well, .netTiers followed the same belief when architecting this solution. It's wonderful to be able to use established tools that give us the opportunity to leverage best practices and follow the guidance of the Microsoft Patterns and Practices group! .netTiers is built on top of enterprise library, which itself is an awesome framework of pluggable provider-based common needs that many applications require. The blocks offer Data Access, Logging, Exception Handling, Application Health Metrics, Caching, Security, Cryptography, and more!!! Meaning, that out of the box, you can begin to use any of these features and not have to write, or purchase a component that does this for you. It's already in place. You can find a ton of information and a hands on lab at the link provided below.
Excerpt from Enterprise Library Developer Site
Microsoft patterns & practices: Application Blocks
Application Blocks are reusable source-code components that provide proven solutions to common development challenges. They can be integrated as is into applications, or they can be extended or customized. patterns & practices Application Blocks address specific recurring problem domains such as data access, logging, user interface process, and composite user interfaces. EditNUnit & VSTS:
What would an application be without unit testing? Unit testing has been such an integral aspect of today's applications because it allows the developer to continue forging forward. There's nothing worse than to add a new feature to your application which breaks 10 other areas of the site you wrote a couple years ago, or worse, you didn't write and have no knowledge of the way it works. Unit testing allows you to write small tests that cover your methods and chunks of code for correctness. You essentially attempt to simulate all the possible scenarios your application is supposed to cover, and even intentionally break some areas to ensure that your application can respond appropriately.
Another reason unit tests are so heavily favorable is that they also give great insight to how the API is supposed to behave. You can see how the API is built out and how you would interact with your entities that were generated for your domain!
.netTiers offers unit tests for your data API out of the box. This helps when you make customizations to your data layer API, and you want to ensure that you did not break any of the existing code base. There are many testing suites that exist today, but we offer support for the two most prominent suites:
NUnit
and
Visual Studio Team System. If you plan on using NUnit, we highly recommend downloading
TestDriven.net, which allows you to kick off the tests easily from within Visual Studio.
1
// From Northwind\Northwind.UnitTests\CategoriesTest.cs
2
/**//// <summary>
3
/// Inserts a mock Categories entity into the database.
4
/// </summary>
5
6[Test]
7public void Step_01_Insert()
8...{
9 // Establish additional pre-conditions here
10
11 Step_01_Insert_Generated();
12
13 // Add additional verification here
14}
15
16// From Northwind\Northwind.UnitTests\CategoriesTest.generated.cs
17/**//// <summary>
18/// Inserts a mock Categories entity into the database.
19/// </summary>
20private void Step_01_Insert_Generated()
21...{
22 Assert.IsTrue(DataRepository.CategoriesProvider.Insert(
23 transactionManager, mock), "Insert failed");
24
25 System.Console.WriteLine(
26 "DataRepository.CategoriesProvider.Insert(mock):");
27
28 System.Console.WriteLine(mock);
29}
EditSolution Layout:
In the
Getting Started Document, you caught a glimpse of the generated projects and saw that they were split up into several different projects. While this can be a bit overwhelming at first if you are unfamiliar with multi-tier design. Again, I emplore you to take a moment and read a bit about n-tier design somewhere if you do not understand why we generate loosely coupled layers. Please read through the
Designing Data Tier Components and Passing Data Through Tiers white paper as an excellent primer and will get you caught up in how the .netTiers architecture works.
What does it mean to be loosely coupled? A loosely coupled architecture is an open architecture in which the interaction is usually done as generically as possible, with minimal information from the other layers. For example, the Data Access Layer is an abstraction layer which only knows about the Data Access API methods. It has no specific Database Knowledge or Web Service knowledge. Using the API for an Orders table, we can determine that the Abstract provider will know various aspects of the OrdersProvider API, like, GetByOrderId(), Insert(), Update(), Delete(). But in these methods you will not find any sql or any commands executing to the database. This layer essentially defines the contract that any Provider must implement before it can successfully interoperate with the other Providers.
This is useful for being able to switch data providers at will from for example, the SQL Server provider to the Web Service Provider, and back.
This seems like a lot more code and work, Why is this useful?The facts are that technology changes frequently due to several factors. For example, often businesses are bought or sold and the new company now wants to do everything in the newest technologies, and wants to eliminate the overhead of using enterprise library for data access. They want to use
DLinq from the .NET Framework 3.0, next generation data access from Microsoft. You can easily create a DLinq provider which would plug right in, and your API is still in-tact and the risk of breaking code across tiers is minimal.
Overall, the projects are layered like (using Northwind as an example):
Edit.netTiers API Layers
netTiers Solution
- Northwind.Entities - The entity layer is modeled after the TableModule, Data Transfer Object, and Domain patterns. This layer is only intended to move data across the tiers while still maintaining state and data integrity. Customizations would include wanting to add some basic business rules, such bounds checking, valid data type, lengths, formats; Things like DisplayName that combines two properties, such as FirstName + " " + LastName from a user class for binding purposes.
- Northwind.Data - The data abstraction layer that implements a single DataRepository interface into the generated API. This is the entry point into your data and has knowledge about the types of data calls your API will support, however has no knowledge in the provider implementation.
- Northwind.Data.SqlClient - A Microsoft Sql Server provider for your entities.
- Northwind.Data.WebServiceClient - A Web Service Provider that is a client and will make all data calls through the webservice endpoint found below. This makes it easy for you to use .netTiers through a remote client, such as a smart client.
- Northwind.Services or Northwind.Domain - This layer provides application boundaries into your complex business rules and data API. The options you have here are using the ServiceLayer(aka Manager) Pattern or the DomainModel (aka ActiveRecord) pattern. You would define all of the complex behavior in these layers, but you don’t want to implement all of the behavior here. This layer contains Processors which you can implement the defined behaviors as Strategies.
- Northwind.WebServices - The disconnected web services project provides a web service endpoint that exposes your data API for consumption. This is actually both a provider and a consumer since it is consumed by the Web Service Client layer, but consumes the Sql Client at the server end of this architecture.
Edit.netTiers API Consumers
- Northwind.UnitTests - The unit tests consume the API and provide a level of unit testing for the data access API.
- Northwind.Web - This layer provides an extensive set of ASP.net controls and utilities that assist you in using your data efficiently in your web applications.
- Northwind.Website - This is a starter website should you choose one, which will automatically create a website project for you, with the proper references and you can begin to work immediately once generating your project.
Edit.netTiers Patterns:
The .netTiers team tries very hard to write an application with best practices in mind. We've followed the guidances given from Microsoft in how best to use their platform, which includes the usage of many of the Microsoft Patterns and Practices Team Libraries.
Here's general information on the patterns used in .netTiers 2.
Information mostly aggregated from these wonderful developer resources:patternshare.org |
dofactory.com |
DavidHayden.comEditServiceLayer
http://martinfowler.com/eaaCatalog/serviceLayer.html
Processors
By default is a Pipeline:
http://www.enterpriseintegrationpatterns.com/PipesAndFilters.html
but easily can be used with workflow management in:
http://www.enterpriseintegrationpatterns.com/ProcessManager.html
Each Individual Processor uses a:
Command
http://www.dofactory.com/Patterns/PatternCommand.aspxFlexible enough to be used within a strategy passed into the ctor to manage different behaviors in complex logic.
http://www.dofactory.com/Patterns/PatternStrategy.aspxDomainModel + ActiveRecord
http://martinfowler.com/eaaCatalog/domainModel.htmlhttp://martinfowler.com/eaaCatalog/activeRecord.html
EditData Access Layer
Singleton, Decorator
http://msdn2.microsoft.com/en-us/library/ms998426.aspxhttp://www.dofactory.com/Patterns/PatternDecorator.aspxData Transfer Objects:
http://martinfowler.com/eaaCatalog/dataTransferObject.html
Repository Provider:
http://davidhayden.com/blog/dave/archive/2004/05/19/259.aspxEditEntity Layer
Each Entity -
Memento,
State,
DomainModel,
TableModule
http://www.dofactory.com/Patterns/PatternMemento.aspx
http://www.dofactory.com/Patterns/PatternState.aspx#_self2
http://martinfowler.com/eaaCatalog/domainModel.htmlhttp://martinfowler.com/eaaCatalog/tableModule.html
Entity Factory
http://www.dofactory.com/Patterns/PatternFactory.aspxWebService Client - Proxy
http://www.dofactory.com/Patterns/PatternProxy.aspxSql Expression - Builder
http://www.dofactory.com/Patterns/PatternBuilder.aspx