Forkwind is a tutorial on how to build a well designed .net application. This is the 4th part of our forkwind implementation. If you are not aware of the master thread and forkwind, please go here first for introduction.
Introduction:
In this part, we are going to dive in to some theory again. We are going to discuss two design methodologies. Domain driven design and record oriented design. In my honest opinion both methodologies are decent. But slowly record oriented design isbecoming obselete. Actually this discussion is not very popular in the software world beyond .net. Most of the recent frameworks like rails and java frameworks use domain driven design as de facto standard. .NET world however is quite lagging in this manner.
What is Record Oriented Development ?
I am not going to make a formal definition. But in practice, record oriented development focuses on the records within the database. It is record centric in a sense. Database records are passed within layers. Records are just mere containers and having no semantic meaning. In .NET world datasets used together with datatables are good examples to this methodology. They are mostly typeless but just records. In .net 2.0 we had Typed Datasets but they are merely generated code.
Usually the first step in record driven development is to design the database , tables and relations and build your application on top of that. If we were developing Forkwind in a record oriented manner, then first we would have created tables like Company, Product, Supplier ,etc
What is Domain Oriented Development ?
In domain driven development, we define domain entities to solve our particular problem. It is a more object oriented approach. For example Forkwind is an application to keep track of orders to customers and suppliers. So we create typed objects like Customer and Supplier as a first step. We generally ignore the database design to later part thanks to ORM tools and object databases. Though there is one exception to that : If the database is already created and with full of data then we have to adapt our domain entities according to that tables. This is a common and painful scenario with domain driven development.
Why domain driven development is not popular in .NET ?
This has historical reasons. Before .NET, I was coding with MFC and pure Win32 for gui stuff in windows. Frankly speaking both MFC and Win32 was dirtier than my toilet. The api was terrible. Then came the Visual Basic 6. When VB6 emerged, my neigbour's son became a more productive programmer than I am. VB6, which I never liked, allowed developers quickly design applications. Managers liked it very much because all that matters was the software running. They are not concerned with the maintenance nightmare coming from "Quick and Dirty" approach of VB6. I also conspire Bill Gates himself was a big pusher of Visual Basic because of his personal sympathy to BASIC. VB6 was using ADO to connect database which is completely record oriented. So when .NET emerged , record oriented approach already widely accepted in .net world. Also microsoft used this fact to sell its IDE so called Visual studio to show how easy to create an application just by dragging and dropping a database table to the screen. They made a propaganda on that this approach such that you are suppose to produce quicker (but dirtier) applications and you will save money on development costs (but lose on maintenance). The last reason is the Microsof's failed ORM Mapper called Objectspaces. Microsoft was planning to deliver this ORM mapper with Visual Studio 2005. But project failed miserably. So MS silently carried on ignoring domain driven development methodologies till 2007-2008 where we have linq to sql and ADO.NET Entity framework now.
Enough history let's get into technical details:
Domain Driven Development Pros:
* More Object Oriented approach
* Much better maintenance
* Sounds more correct
Domain Driven Development Cons:
* Less mainstream on .NET
* Requires skill!!
* You have to use things like ORM
Record Driven Development Pros:
* Easier for novice
* Visual studio tools integrates better
* Faster development (though pace diminishes if project grows)
Record Driven Development Cons:
* Likely to lead maintenance nightmare!!!
Basically Domain driven development dissects a complex problem into smaller pieces. But it can be complex at times. Record driven approach is more simple, just get the records from the db and publish. Since we usually aim better design and better maintence in general , domain driven approach is favorable to me. And that's what we are doing in Forkwind.
In the next part * Forkwind Part 5: A first visit to unit testing: (Not Available at the moment) again we are back to coding. We will write our first unit tests for Forkwind. Till then stay tuned!!
Showing posts with label Forkwind. Show all posts
Showing posts with label Forkwind. Show all posts
Thursday, June 19, 2008
Wednesday, June 18, 2008
Forkwind Part 3: Creating the domain model :
This is the 3rd part of our forkwind implementation. If you are not aware of the master thread and forkwind, please go here first.
Introduction
After discussing about modules and assemblies in part 2, we can again get our hands dirty with the code. Once the project skeleton up , the next thing is to implement the model or the domain model.
Technically the domain model has nothing to do with code but this is something you should be able to generate while thinking about the problem or discussing with the customer. For instance, the Forkwind application is a solution for tracking orders from suppliers and customers. So considering these, what concepts are being visualized in our minds ? We have a supplier and we have a customer. We also have orders. Since we have orders, we have also products. This is a very basic abstraction but it is extremely useful. We should also be able to tell the relationship type between these entities. For instance a supplier has many products
You should be able to do this just by thinking or with a piece of paper and pen. The rest of the implementation is just filling the gaps and details.
Forkwind Domain Model:
Introduction
After discussing about modules and assemblies in part 2, we can again get our hands dirty with the code. Once the project skeleton up , the next thing is to implement the model or the domain model.
Technically the domain model has nothing to do with code but this is something you should be able to generate while thinking about the problem or discussing with the customer. For instance, the Forkwind application is a solution for tracking orders from suppliers and customers. So considering these, what concepts are being visualized in our minds ? We have a supplier and we have a customer. We also have orders. Since we have orders, we have also products. This is a very basic abstraction but it is extremely useful. We should also be able to tell the relationship type between these entities. For instance a supplier has many products
You should be able to do this just by thinking or with a piece of paper and pen. The rest of the implementation is just filling the gaps and details.
Forkwind Domain Model:
Since we have modelized the basics, we can fill the gaps by simply scetching an informal class diagram. I use a small program called dia but a piece of paper is just good. No need for fancy uml software.
Here's my diagram:
If it it doesn't make sense to you you can follow it from the source where I posted at the end of this post.
Here's my solution explorer:
When you look at the code you will see all properties marked as virtual. This is due to we will use NHibernate in the next posts and in order to do lazy loading properties must be virtual. Don't worry we will come to that.
Let's go each of these classes briefly:
DomainObject: This is the base class for all our entities. This is the place we can put common code. Currently it has an Id field. This for mostly nhibernate but it is practical to have an Id for each of our domain entites (I would use a guid type for an object database like db4o). It's type is long.
Company: This is the base type for suppliers and customers since we assume they are companies. It has general properties like Name, Adress etc. A company has one address.
Customer : This is derived from company and represents our customers. Also a customer has many customer orders.
Supplier : This is dervied from company and represents our suppliers. Also a supplier has many supplier orders and a supplier has many products.
Product: This represents a product type actually not the product itself. This is a common confusion when developing our models. Our product has a property called Quantity. But for an instance of the product the quantity would be always one. But in general we model the product type as model. A product can belong to many categories and a product belongs to a supplier.
Category: This is for categorizing our products. It is hierachical. A category has one parent category and a category has many children categories and a category has many products.
Order: This is the base class for SupplierOrder and CustomerOrder. Why I seperated those into two ? This is completly with instict. I just presume they might have different behaviorus and properties depending on your company policy. An Order has many OrderLineItems.
SupplierOrder: Derived from Order. A SupplierOrder has a supplier
CustomerOrder: Derived from Order. A CustomerOrder has a Customer
OrderLineItem: This represents an each line in our Orders. An OrderLineItem has a Product.
OrderStatus: This is basically an enum represents the state of our orders. It can be pending (by default this is set in the Order's constructor), cancelled or completed
Address: Represents an address used by a company.
This is pretty much about our domain model. It looks okay to me and it is ready to be cooked. Sure we might refactor it. One thing you should notice, we haven't done anything about database. Because this is domain driven design, it is the domain that derives our design and we completely ignore the database unlike the traditional approach.
The code is here. In the next part Forkwind Part 4: Domain Driven Design and Record Driven Design we will get into some theory and investigate why we have chosen domain driven design over a database driven design. Till then stay tuned!
Here's my diagram:
If it it doesn't make sense to you you can follow it from the source where I posted at the end of this post.
Here's my solution explorer:
When you look at the code you will see all properties marked as virtual. This is due to we will use NHibernate in the next posts and in order to do lazy loading properties must be virtual. Don't worry we will come to that.
Let's go each of these classes briefly:
DomainObject: This is the base class for all our entities. This is the place we can put common code. Currently it has an Id field. This for mostly nhibernate but it is practical to have an Id for each of our domain entites (I would use a guid type for an object database like db4o). It's type is long.
Company: This is the base type for suppliers and customers since we assume they are companies. It has general properties like Name, Adress etc. A company has one address.
Customer : This is derived from company and represents our customers. Also a customer has many customer orders.
Supplier : This is dervied from company and represents our suppliers. Also a supplier has many supplier orders and a supplier has many products.
Product: This represents a product type actually not the product itself. This is a common confusion when developing our models. Our product has a property called Quantity. But for an instance of the product the quantity would be always one. But in general we model the product type as model. A product can belong to many categories and a product belongs to a supplier.
Category: This is for categorizing our products. It is hierachical. A category has one parent category and a category has many children categories and a category has many products.
Order: This is the base class for SupplierOrder and CustomerOrder. Why I seperated those into two ? This is completly with instict. I just presume they might have different behaviorus and properties depending on your company policy. An Order has many OrderLineItems.
SupplierOrder: Derived from Order. A SupplierOrder has a supplier
CustomerOrder: Derived from Order. A CustomerOrder has a Customer
OrderLineItem: This represents an each line in our Orders. An OrderLineItem has a Product.
OrderStatus: This is basically an enum represents the state of our orders. It can be pending (by default this is set in the Order's constructor), cancelled or completed
Address: Represents an address used by a company.
This is pretty much about our domain model. It looks okay to me and it is ready to be cooked. Sure we might refactor it. One thing you should notice, we haven't done anything about database. Because this is domain driven design, it is the domain that derives our design and we completely ignore the database unlike the traditional approach.
The code is here. In the next part Forkwind Part 4: Domain Driven Design and Record Driven Design we will get into some theory and investigate why we have chosen domain driven design over a database driven design. Till then stay tuned!
Tuesday, June 17, 2008
Forkwind: Part 2: Modularity, .NET Assembly and Namespaces
This is the 2nd part of our forkwind implementation. If you are not aware of the master thread and forkwind, please go here first.
Introduction
In this article, I'll briefly dig modularity and how it maps into .NET assemblies. Modularity is simply dividing our applications into smaller modules. The benefits are obvious: Debugging is easer, and multiple people in the team can work in different modules without affecting each other. Finally, modules are rather isolated so further modifications can be made to one module without breaking the system. This provides us good maintainability for a particular project.
In .NET world, our assemblies act as modules (formally, a module is a code file in .NET but we will ignore this fact to prevent confusion). Each project we create in Visual Studio corresponds to an assembly. It can be a dll or it can be an exe. Even for a web application (and not for a website!) all we get is a dll along with some aspx files. .Net assemblies also provide us additional benefits like versioning, security and ease of deployment.
Assemblies in Forkwind:
In Forkwind, in Part 1 as you remember we have generated several projects/assemblies. This may seem natural to you since we have a layers: a gui layer , a test layer etc. But why did we create separate projects ? It is technically possible that we could have created a web application project and we could build all our code right into that (and even including unit testing). Is it to reduce the pain of an environment with multiple developers ? Certainly not. If you read above my informal definition to modularity, you will understand the reason. We are looking for good design! And good design dictates us building our application in modules. In some case it is perfectly valid to have a single assembly and in some cases using multiple assemblies can be overkill. Only experience can tell when to use what.
Specifically talking on .NET my rule of thumb is if I expect a layer to be replaceable with another equivalent code, I create an assembly for that. So my repository implementation might change in the future , thus I create an assembly for that particular layer. If not I would lean towards a more monolithic design. Is this my only criteria no ? For a plug-in like system again you have to create assemblies so that you can load them on runtime without stopping your main executable. Finally an assembly like Forkwind.Test should be seperate. Because it doesn't belong to code. It is ony useful for testing. It has no business within the production environment to create excessive code. So for optional components again I create an assembly. Finally when there are issues of versioning, or a different security setting is concerned I create an assembly for that again. The rest really depends on your taste.
What about namespaces ?
From time to time, I see some novice developers are confused about a namespace and the assembly name. This is due to mainly relying on Visual Studio's intellisense. Namespaces and assemblies has nothing to do with each other actually. They are apples and oranges. A namespace's solely purpose is to prevent Class name clashes. It is NAME-SPACE ! An assembly is more like a module. And just because you can use a namespace like System.Configuration appears with intellisense in Visual studio, it doesn't mean that you are actually making use of the System.Configuration assembly. In deed, all you see is the System.Configuration namespace within System assembly!
One exception to this , namespaces have another use in C# 3.0 which allows resolution for extension methods.
So that's it for part 2. No new code in this part. But we will get our hand very dirty in next part:
* Forkwind Part 3: Creating the domain model
Stay tuned!!!
Introduction
In this article, I'll briefly dig modularity and how it maps into .NET assemblies. Modularity is simply dividing our applications into smaller modules. The benefits are obvious: Debugging is easer, and multiple people in the team can work in different modules without affecting each other. Finally, modules are rather isolated so further modifications can be made to one module without breaking the system. This provides us good maintainability for a particular project.
In .NET world, our assemblies act as modules (formally, a module is a code file in .NET but we will ignore this fact to prevent confusion). Each project we create in Visual Studio corresponds to an assembly. It can be a dll or it can be an exe. Even for a web application (and not for a website!) all we get is a dll along with some aspx files. .Net assemblies also provide us additional benefits like versioning, security and ease of deployment.
Assemblies in Forkwind:
In Forkwind, in Part 1 as you remember we have generated several projects/assemblies. This may seem natural to you since we have a layers: a gui layer , a test layer etc. But why did we create separate projects ? It is technically possible that we could have created a web application project and we could build all our code right into that (and even including unit testing). Is it to reduce the pain of an environment with multiple developers ? Certainly not. If you read above my informal definition to modularity, you will understand the reason. We are looking for good design! And good design dictates us building our application in modules. In some case it is perfectly valid to have a single assembly and in some cases using multiple assemblies can be overkill. Only experience can tell when to use what.
Specifically talking on .NET my rule of thumb is if I expect a layer to be replaceable with another equivalent code, I create an assembly for that. So my repository implementation might change in the future , thus I create an assembly for that particular layer. If not I would lean towards a more monolithic design. Is this my only criteria no ? For a plug-in like system again you have to create assemblies so that you can load them on runtime without stopping your main executable. Finally an assembly like Forkwind.Test should be seperate. Because it doesn't belong to code. It is ony useful for testing. It has no business within the production environment to create excessive code. So for optional components again I create an assembly. Finally when there are issues of versioning, or a different security setting is concerned I create an assembly for that again. The rest really depends on your taste.
What about namespaces ?
From time to time, I see some novice developers are confused about a namespace and the assembly name. This is due to mainly relying on Visual Studio's intellisense. Namespaces and assemblies has nothing to do with each other actually. They are apples and oranges. A namespace's solely purpose is to prevent Class name clashes. It is NAME-SPACE ! An assembly is more like a module. And just because you can use a namespace like System.Configuration appears with intellisense in Visual studio, it doesn't mean that you are actually making use of the System.Configuration assembly. In deed, all you see is the System.Configuration namespace within System assembly!
One exception to this , namespaces have another use in C# 3.0 which allows resolution for extension methods.
So that's it for part 2. No new code in this part. But we will get our hand very dirty in next part:
* Forkwind Part 3: Creating the domain model
Stay tuned!!!
Forkwind Part 1: Creating skeleton of the application layers as . net assemblies
This is the first part of our forkwind implementation. If you are not aware of the master thread and forkwind, please here first
As being pragmatic without diving into deep theoretical discussions we first create our project skeleton.
As seen in the picture our forkwind implementation consists of 8 projects which are also assemblies. If you are unfamiliar with assembly concept just hold your breath a while that we will discuss modularity and assemblies in the next part Forkwind: Part 2: Modularity, .NET Assembly and Namespaces.
Let's go through each assembly and discuss why we need them briefly:
Forkwind.Core: Obviously this is our core assembly. We are planning to put most of our business logic , our domain entities service layers here. One key point is Forwind.Core should not depend any other assemblies but be able to self compiled. In this case it only uses Forkw
Forkwind.Repository: The name repository may look unfamiliar to you. But this is simply an evolutioned version of your old data access layers or DAO's or what ever you call it. Why I call it Repository ? The simple answer for now is we have domain objects and one of our aims is to encapsulate data access as internals so that our application is unaware of the datasource. More details will come in following parts. Don't worry about it at the moment.
Forkwind.Presenter: This is our presenter layer. If you are unfamiliar for presenters their main job is to bridge the core layer and the gui. They prevent business logic leaking to UI layer.
It's mostly modeled after Martin Fowler's model view presenter. And again we will discuss it throughly. For the time being it provides a GUI agnostic backend , also enables us to unit test our guis.
Forkwind.Test: This is for unit testing obviously. I will use nunit but anyother unit test framework is ok.
Forkwind.Util: This is for general utility stuff. We can make use of C# 3.0 extension methods here as well. All other assemblies may make use of this assembly.
Forkwind.Web: This is our assembly for the web application (and not web site!!).
Forkwind.Console: This is our assembly for a console application which make uses the same backend. It's mainly demonstrative purposes so that it proves our implementation is GUI agnostic. But you can further improve it as you like
Forkwind.Windows : This is our assembly for a windows application which make uses the same backend. It's mainly demonstrative purposes so that it proves our implementation is GUI agnostic. But you can further improve it as you like.
SharedLibraries: This is not a project but a pile of third party libraries to be used by other projects.
Well that's it. Let's see the dependecy of our assemblies:
For simplicity I removed console from diagram but same as Windows and web. All assemblies except references Util. And Test references all other assemblies.
In old designs typically we have GUI -> Business -> Data Dependency. But this doesn't sound correct to me. If business depends on data then any changes on the data layer may break our business layer as well. This is totaly unacceptable. This is why the dependency is inverted here. And our core assembly is stand alone (except it makes use of util). This way it won't be affected of any changes happening in any other assemblies. We will get into details in the following parts so stay tuned!
Code is attached for this section here
Next part is : Forkwind: Part 2:Modularity, .NET Assembly and Namespaces
As being pragmatic without diving into deep theoretical discussions we first create our project skeleton.
As seen in the picture our forkwind implementation consists of 8 projects which are also assemblies. If you are unfamiliar with assembly concept just hold your breath a while that we will discuss modularity and assemblies in the next part Forkwind: Part 2: Modularity, .NET Assembly and Namespaces.Let's go through each assembly and discuss why we need them briefly:
Forkwind.Core: Obviously this is our core assembly. We are planning to put most of our business logic , our domain entities service layers here. One key point is Forwind.Core should not depend any other assemblies but be able to self compiled. In this case it only uses Forkw
Forkwind.Repository: The name repository may look unfamiliar to you. But this is simply an evolutioned version of your old data access layers or DAO's or what ever you call it. Why I call it Repository ? The simple answer for now is we have domain objects and one of our aims is to encapsulate data access as internals so that our application is unaware of the datasource. More details will come in following parts. Don't worry about it at the moment.
Forkwind.Presenter: This is our presenter layer. If you are unfamiliar for presenters their main job is to bridge the core layer and the gui. They prevent business logic leaking to UI layer.
It's mostly modeled after Martin Fowler's model view presenter. And again we will discuss it throughly. For the time being it provides a GUI agnostic backend , also enables us to unit test our guis.
Forkwind.Test: This is for unit testing obviously. I will use nunit but anyother unit test framework is ok.
Forkwind.Util: This is for general utility stuff. We can make use of C# 3.0 extension methods here as well. All other assemblies may make use of this assembly.
Forkwind.Web: This is our assembly for the web application (and not web site!!).
Forkwind.Console: This is our assembly for a console application which make uses the same backend. It's mainly demonstrative purposes so that it proves our implementation is GUI agnostic. But you can further improve it as you like
Forkwind.Windows : This is our assembly for a windows application which make uses the same backend. It's mainly demonstrative purposes so that it proves our implementation is GUI agnostic. But you can further improve it as you like.
SharedLibraries: This is not a project but a pile of third party libraries to be used by other projects.
Well that's it. Let's see the dependecy of our assemblies:
For simplicity I removed console from diagram but same as Windows and web. All assemblies except references Util. And Test references all other assemblies.
In old designs typically we have GUI -> Business -> Data Dependency. But this doesn't sound correct to me. If business depends on data then any changes on the data layer may break our business layer as well. This is totaly unacceptable. This is why the dependency is inverted here. And our core assembly is stand alone (except it makes use of util). This way it won't be affected of any changes happening in any other assemblies. We will get into details in the following parts so stay tuned!
Code is attached for this section here
Next part is : Forkwind: Part 2:Modularity, .NET Assembly and Namespaces
Forkwind: Application Design from Beginner to PRO with .NET and Mono
Introduction:
The purpose of this article is to demonstrate one of the good ways for application design with .NET and Mono. I will be using .NET and C# 3.0 through this but I will be also careful for mono support so your application will be running everywhere. We will develop an application called "Forkwind" which is an imaginary company:). We will do a lot of discussion on the mean while. Feel free to correct me at any point if you disagree with something. Additionally I am not claiming my methodology is the best. It's just something I am happy with it. Lastly this is not my own design. I gathered this information around web. I am inspired Mainly Billy's excellent article
http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx.
But i will slightly diverge from his way and try to do a lot of in depth theoretic discussion. I am expecting this to be a very long series so I'll divde it into some sub parts and , I'll try to implement it every day if I can.
What we are going to do, is to design and code an application called Forkwind. Forkwind does not have to be a web application. The aim is making it so flexible that a console gui or a windows forms will also fit. Forkwind will be a simple crud application but feel free to extend it.
This is the master post for other sub articles so visit this post frequently and I will update and implement articles. Generally I'll first implement the practice then the second post will include the theoretical discussion. Oh yes and I will post real sample code. !!!
Here are the topics:
* Forkwind Part 1: Creating skeleton of the application layers as . net assemblies: (Updated on Jun 17, 2008)
* Forkwind: Part 2: Modularity, .NET Assembly and Namespaces: (Updated on Jun 17, 2008)
* Forkwind Part 3: Creating the domain model : (Updated on Jun 18, 2008)
* Forkwind Part 4: Domain Driven Design and Record Driven Design : (Updated on Jun 19, 2008)
* Forkwind Part 5: A first visit to unit testing: (Not Available at the moment)
* Forkwind Part 6: Why unit testing is so important : (Not Available at the moment)
* Forkwind Part 7: A first visit to persistence and database stuff in Forkwind: (Not Available at the moment)
* Forkwind Part 8: Repository pattern , DAOs and DAL: (Not Available at the moment)
* Forkwind Part 9: What are my persistence options in .net and which one I should use: ( Not Available at the moment)
* Forkwind Part 10: Log4Net putting logging into work: ( Not Available at the moment).
* Forkwind 11: Dependency Injection in Forkwind With Castle Windsor: (Not Available at the moment)
* Forkwind 12: Benefits of Dependency Injection, connecting decoupled pieces: ( Not Available at the moment)
* Forkwind 13: Fowler's Dependency Inversion and Assembly dependence ( Not Available at the moment)
* Forkwind 14: Alternatives to CastleWindsor: Spring .NET, Sturcture Map and unity : (Not Available at the moment)
* Forkwind 15: The need for Service Classes: (Not Available at the moment)
* Forkwind 16: Unit testing revisited ,mocking comes into the scene: (Not Available at the moment)
* Forkwind 17:The GUI: (Not Available at the moment)
* Forkwind 18: Model View Presenter:(Not Available at the moment)
* Forkwind 19: Model View Presenter Continued:(Not Available at the moment)
* Forkwind 20: Unit Testing the GUI:(Not Available at the moment):(Not Available at the moment)
* Forkwind 21: Databinding to ASP.NET:(Not Available at the moment)
* Forkwind 22: A Console and Windows GUI:(Not Available at the moment)
* Forkwind 23: NHibenate in Depth:(Not Available at the moment)
* Forkwind 24: Active Recording With Castle ActiveRecord:(Not Available at the moment)
* Forkwind 25: Active Recording With DB4O:(Not Available at the moment)
* Forkwind 26: AOP and limitations of C# :(Not Available at the moment)
* Forkwind 27: Compacting the application:(Not Available at the moment)
* Forkwind 26: Final Words:(Not Available at the moment)
The purpose of this article is to demonstrate one of the good ways for application design with .NET and Mono. I will be using .NET and C# 3.0 through this but I will be also careful for mono support so your application will be running everywhere. We will develop an application called "Forkwind" which is an imaginary company:). We will do a lot of discussion on the mean while. Feel free to correct me at any point if you disagree with something. Additionally I am not claiming my methodology is the best. It's just something I am happy with it. Lastly this is not my own design. I gathered this information around web. I am inspired Mainly Billy's excellent article
http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx.
But i will slightly diverge from his way and try to do a lot of in depth theoretic discussion. I am expecting this to be a very long series so I'll divde it into some sub parts and , I'll try to implement it every day if I can.
What we are going to do, is to design and code an application called Forkwind. Forkwind does not have to be a web application. The aim is making it so flexible that a console gui or a windows forms will also fit. Forkwind will be a simple crud application but feel free to extend it.
This is the master post for other sub articles so visit this post frequently and I will update and implement articles. Generally I'll first implement the practice then the second post will include the theoretical discussion. Oh yes and I will post real sample code. !!!
Here are the topics:
* Forkwind Part 1: Creating skeleton of the application layers as . net assemblies: (Updated on Jun 17, 2008)
* Forkwind: Part 2: Modularity, .NET Assembly and Namespaces: (Updated on Jun 17, 2008)
* Forkwind Part 3: Creating the domain model : (Updated on Jun 18, 2008)
* Forkwind Part 4: Domain Driven Design and Record Driven Design : (Updated on Jun 19, 2008)
* Forkwind Part 5: A first visit to unit testing: (Not Available at the moment)
* Forkwind Part 6: Why unit testing is so important : (Not Available at the moment)
* Forkwind Part 7: A first visit to persistence and database stuff in Forkwind: (Not Available at the moment)
* Forkwind Part 8: Repository pattern , DAOs and DAL: (Not Available at the moment)
* Forkwind Part 9: What are my persistence options in .net and which one I should use: ( Not Available at the moment)
* Forkwind Part 10: Log4Net putting logging into work: ( Not Available at the moment).
* Forkwind 11: Dependency Injection in Forkwind With Castle Windsor: (Not Available at the moment)
* Forkwind 12: Benefits of Dependency Injection, connecting decoupled pieces: ( Not Available at the moment)
* Forkwind 13: Fowler's Dependency Inversion and Assembly dependence ( Not Available at the moment)
* Forkwind 14: Alternatives to CastleWindsor: Spring .NET, Sturcture Map and unity : (Not Available at the moment)
* Forkwind 15: The need for Service Classes: (Not Available at the moment)
* Forkwind 16: Unit testing revisited ,mocking comes into the scene: (Not Available at the moment)
* Forkwind 17:The GUI: (Not Available at the moment)
* Forkwind 18: Model View Presenter:(Not Available at the moment)
* Forkwind 19: Model View Presenter Continued:(Not Available at the moment)
* Forkwind 20: Unit Testing the GUI:(Not Available at the moment):(Not Available at the moment)
* Forkwind 21: Databinding to ASP.NET:(Not Available at the moment)
* Forkwind 22: A Console and Windows GUI:(Not Available at the moment)
* Forkwind 23: NHibenate in Depth:(Not Available at the moment)
* Forkwind 24: Active Recording With Castle ActiveRecord:(Not Available at the moment)
* Forkwind 25: Active Recording With DB4O:(Not Available at the moment)
* Forkwind 26: AOP and limitations of C# :(Not Available at the moment)
* Forkwind 27: Compacting the application:(Not Available at the moment)
* Forkwind 26: Final Words:(Not Available at the moment)
Subscribe to:
Posts (Atom)