Recently one of my friends notified me that the article for the programming language Nemerle has been deleted from Wikipedia. And I am very upset about it . This language is still very active and widely used in russian communities and I myself is one of the developers. I also have production projects with it. Here you can read the discussion
http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Nemerle
It seems this Monsanto guy http://monsan.to/ is one of the power abusers, and despite all the discussion he has deleted it with no solid reason. Shame on him, shame on wikipedia for this action.
I always thought wikipedia is one of the most neutral (at least trying to be ) places to gather info but this sensorship , this irresponsiblity or what ever you call is totally unacceptable. You can tell me it is a non notable language so has no right to exist in wikipedia. We could debate about it. But the lanaguage has 8 years of constant effort of developers, how would you feel if your baby is treated like this ?
Here you can see all the checkin history of nemerle:
http://code.google.com/p/nemerle/source/list
and this Monsanto guy just deletes it shame on him!
Sunday, February 13, 2011
Saturday, February 07, 2009
C# versus C++ versus Java performance comparison
The performance comparison of C#, Java and C++ was always a controversial subject. Many people who are unfamiliar with JIT'ed environments claimed anything runs on JIT is too slow compared to C++. On the other hand people who actually use Java and C# usually claimed the otherwise that performance impact is negligable. Here's a nice chart I've found that a friend in freenode IRC server pointed me. These benchmarks are done by Matt R Warren (aka Moridin8 in irc.freenode.net) and his original site is http://www.csharp-architect.com
According to below chart, choosing C++ just for the sake of performance doesn't seem very feasable to me. Remember : Engineers are expensive and servers are not!
According to below chart, choosing C++ just for the sake of performance doesn't seem very feasable to me. Remember : Engineers are expensive and servers are not!
Sunday, February 01, 2009
Don't wait for C# 5, use Nemerle Now !!!
Hello ,
I mentioned nemerle before as C# glorified here . As you know C# 5.0 will came with compiler services that allows us to run dynamic code on runtime. Mono has already have it but it is not available to Windows at the moment (you can reference gmcs on windows but with limited support only). So here's our example:
I mentioned nemerle before as C# glorified here . As you know C# 5.0 will came with compiler services that allows us to run dynamic code on runtime. Mono has already have it but it is not available to Windows at the moment (you can reference gmcs on windows but with limited support only). So here's our example:
using System;
using System.Console ;
using Nemerle.Evaluation.Evaluator ;
module Program
{
Main() : void
{
def function = EvaluateExpression( "x => x + 1.0" ) :> double -> double ;
Console
.WriteLine(function(2.0));
}
}
The above code outputs 3!! Simply wonderful and best of all this code is in visual studio with full intellisense as below:
Just install nemerle from http://nemerle.org and add Nemerle.Macros and Nemerle.Evaluator as reference and run the code that's it!
Sunday, November 16, 2008
How to serialize Lambda Expressions
At times I need to serialize my Lambda Expressions, to pass to some web service . Normally this wasn't possible but I realized the MetaLinq project allows it. MetaLinq actually grants us modifiable Expression trees. As you might now know Expression Trees are immutable just like strings. Anyway let's serialize and deserialize a Lambda expression within the code:
Expression<Func<int,int>> myLambda = z => z*z ;
// Create a mutable expression, we are using ExpressionBuilder namespace in MetaLinq here
var mutableExpression = ExpressionBuilder.EditableExpression.CreateEditableExpression(myLambda);
// Serialize it
var serializer = new XmlSerializer(typeof(EditableLambdaExpression));
var sw = new StringWriter();
serializer.Serialize(sw, mutableExpression);
// Get the lambda as string, actually sw.ToString() will give us it in string form
var sr = new StringReader(sw.ToString());
var anotherSerializer = new XmlSerializer(typeof(EditableLambdaExpression));
// Deserialize it
var myex = anotherSerializer.Deserialize(sr) as EditableExpression;
// Convert it to lambda expresion
var myNewLambda = myex.ToExpression() as LambdaExpression;
// Invoke it, outputs 16 as expected
Console.Write(myNewLambda.Compile().DynamicInvoke(4));
So this shows us how to convert an expression to string and restore back to expression and invoke it. DynamicInvoke used here since I assumed we don't know the type here. I hope you find it useful
Expression<Func<int,int>> myLambda = z => z*z ;
// Create a mutable expression, we are using ExpressionBuilder namespace in MetaLinq here
var mutableExpression = ExpressionBuilder.EditableExpression.CreateEditableExpression(myLambda);
// Serialize it
var serializer = new XmlSerializer(typeof(EditableLambdaExpression));
var sw = new StringWriter();
serializer.Serialize(sw, mutableExpression);
// Get the lambda as string, actually sw.ToString() will give us it in string form
var sr = new StringReader(sw.ToString());
var anotherSerializer = new XmlSerializer(typeof(EditableLambdaExpression));
// Deserialize it
var myex = anotherSerializer.Deserialize(sr) as EditableExpression;
// Convert it to lambda expresion
var myNewLambda = myex.ToExpression() as LambdaExpression;
// Invoke it, outputs 16 as expected
Console.Write(myNewLambda.Compile().DynamicInvoke(4));
So this shows us how to convert an expression to string and restore back to expression and invoke it. DynamicInvoke used here since I assumed we don't know the type here. I hope you find it useful
Friday, June 20, 2008
Web development: Ruby on Rails versus ASP.NET , Flex, PHP and other Java stuff
I've got some feedback from my earlier post on ASP.NET versus Others . In that particular post I claimed ASP.NET WebForms works best for me and I presented my own reasons why I think that way. I might be a little biased may be so I'd like to share my opinions for the other side of the equation, namely Rails versus Others:
There is an old saying that, "Teacher will appear , when the student is ready". The fundemantal reason rails emerged was because there was a need for it, mainly from java developers. Java web frameworks generally have excellent architectures. They are clean and they follow good design practices. However following good design practices made them a bit more academic rather than practical. First the EJB 1 and 2 nightmares frustrated java developers then they settled to some ground with Spring and Hibernate. Although this solution was acceptable, the development overhead was rather large. The idea beyond rails is to compact this entire J2ee thingy to an acceptable size and replace a verbose language like java with an elegant language called ruby and we got rails.
When I first dived into rails I really thought that was the answer I was looking for. So I loved it too much. (Then I went back to asp.net. But I wouldn't do that if there were no mono. I am biased against MS)
Ruby had two main philosophies. "Convention over configuration" and "Don't repeat yourself". We will discuss about them. Also rails was the main push behind the RESTFUL Webservices.
Let's get to Pros and Cons of Rails:
Pros of Ruby On Rails:
* Open Source and Community Driven
* Cross platform, works every where
* Ruby is an elegant language
* Extremely Scalable (a front end proxy balancer will do it)
* Built in unit testing and ajax support
* Clean seperation of layers
* Zero configuration (convention over configuration)
* Extremely flexible
* Main stream, good community and lot's of books
Well this are the good things come into my mind. Looks promising right ? Let's see the other side of the equation.
Cons of Ruby On Rails:
* Single threaded!!! Wow this is quite intersting for a web framework. Fortunately this doesn't prevent us to build scalable applications
* No unicode yet. You can over come this with JRuby on Rails and IronRuby on Rails
* Green threads. It doesn't use real os threads. Look above.
* The down side of the MVC pattern. You have to type a lot of html
* Database abstraction is too thin. This is something I don't like. The columns in your db implictly becomes properties of your classes. Even if there is no code !!!
* Most software shops don't know about it. So it is unlikely that you can use it at work.
Well that's all in my mind. Let's get into one by one comparison
Ruby on Rails versus Java frameworks:
Now they say a picture is worth a thousand words. That's a true comparison of java frameworks and rails. It basicly eliminates boring stuff like xml configuration of spring and hibernate. Sure Java frameworks is far more powerful than rails. But if you say who needs an 800 pounds of gorilla. Then rails is the right way to go. Note that Java also have JRuby on Rails and Groovy on Rails. This comparison excludes them but points the traditional approach of java web frameworks. I know this isn't enough for technical comparison but that's all I am gonna say about it now.
Ruby on Rails versus PHP:
Yes I am a php basher. Compared to plain PHP rails is superior Period. Plain php is too old. It's like COBOL imho. And the irony is Facebook uses PHP. Well... But PHP has a lot of grown frameworks. Even Rails like ones like Cake or Symfony. A quick google will tell you more. But my suggestion would be to stay away from PHP unless you are dealing with legacy stuff.
Ruby on Rails versus ASP.NET:
I already made a detailed comparsion ASP.NET versus Others. Telling why I found ASP.NET superior. But unlike my php comparison , I find this is a matter of personal taste. Rails is an excellent framework offers valid solutions. If you like more componentize approach with .NET/mono power then ASP.NET is the way to go. Otherwise rails may suit you better.
One technical thing rails is better is that it can emulate true bidirectional associations. For instance:
my_school.students << my_student
implicitly does a my_student.School = my_school
The same situation is extremely difficult to achive with static languages like C#.In general you do explicitly
mySchool.Students.Add(myStudent);
myStudent.School = mySchool;
Ruby on Rails versus Flex:
Now this can't be a comparison because Flex is for pure front end. And you can perfectly use Flex with Rails. Even there is a book for it. Flexible Rails. Some people call Flex+ Rails as the RIA Nirvana. I told you I like a componentized approach. Flex is perfect for that. And rails is very good at serializing the domain data back and forth to Flex. If you can tolarate a flash thingie running inside your application (which I can't!) this is a perfect way to go.
Others:
Wheather rails is a hype or not, it is a really milestone in web application programming. It inspired other web framework developers a lot. Python got Django and TurboGears, PHP got Cake and Symfony, ASP.NET got MonoRail and ASP.NET MVC. Unfortunately I am not involved with them so I can't really compare them.
Conclusion:
If you tried others and still not satisfied try rails. I am sure that you won't regret. And where do you start ? I personally start with the Agile book available on rails' web site. But there is a huge documentation & screen casts on web too. Good luck !
There is an old saying that, "Teacher will appear , when the student is ready". The fundemantal reason rails emerged was because there was a need for it, mainly from java developers. Java web frameworks generally have excellent architectures. They are clean and they follow good design practices. However following good design practices made them a bit more academic rather than practical. First the EJB 1 and 2 nightmares frustrated java developers then they settled to some ground with Spring and Hibernate. Although this solution was acceptable, the development overhead was rather large. The idea beyond rails is to compact this entire J2ee thingy to an acceptable size and replace a verbose language like java with an elegant language called ruby and we got rails.
When I first dived into rails I really thought that was the answer I was looking for. So I loved it too much. (Then I went back to asp.net. But I wouldn't do that if there were no mono. I am biased against MS)
Ruby had two main philosophies. "Convention over configuration" and "Don't repeat yourself". We will discuss about them. Also rails was the main push behind the RESTFUL Webservices.
Let's get to Pros and Cons of Rails:
Pros of Ruby On Rails:
* Open Source and Community Driven
* Cross platform, works every where
* Ruby is an elegant language
* Extremely Scalable (a front end proxy balancer will do it)
* Built in unit testing and ajax support
* Clean seperation of layers
* Zero configuration (convention over configuration)
* Extremely flexible
* Main stream, good community and lot's of books
Well this are the good things come into my mind. Looks promising right ? Let's see the other side of the equation.
Cons of Ruby On Rails:
* Single threaded!!! Wow this is quite intersting for a web framework. Fortunately this doesn't prevent us to build scalable applications
* No unicode yet. You can over come this with JRuby on Rails and IronRuby on Rails
* Green threads. It doesn't use real os threads. Look above.
* The down side of the MVC pattern. You have to type a lot of html
* Database abstraction is too thin. This is something I don't like. The columns in your db implictly becomes properties of your classes. Even if there is no code !!!
* Most software shops don't know about it. So it is unlikely that you can use it at work.
Well that's all in my mind. Let's get into one by one comparison
Ruby on Rails versus Java frameworks:
Now they say a picture is worth a thousand words. That's a true comparison of java frameworks and rails. It basicly eliminates boring stuff like xml configuration of spring and hibernate. Sure Java frameworks is far more powerful than rails. But if you say who needs an 800 pounds of gorilla. Then rails is the right way to go. Note that Java also have JRuby on Rails and Groovy on Rails. This comparison excludes them but points the traditional approach of java web frameworks. I know this isn't enough for technical comparison but that's all I am gonna say about it now.
Ruby on Rails versus PHP:
Yes I am a php basher. Compared to plain PHP rails is superior Period. Plain php is too old. It's like COBOL imho. And the irony is Facebook uses PHP. Well... But PHP has a lot of grown frameworks. Even Rails like ones like Cake or Symfony. A quick google will tell you more. But my suggestion would be to stay away from PHP unless you are dealing with legacy stuff.
Ruby on Rails versus ASP.NET:
I already made a detailed comparsion ASP.NET versus Others. Telling why I found ASP.NET superior. But unlike my php comparison , I find this is a matter of personal taste. Rails is an excellent framework offers valid solutions. If you like more componentize approach with .NET/mono power then ASP.NET is the way to go. Otherwise rails may suit you better.
One technical thing rails is better is that it can emulate true bidirectional associations. For instance:
my_school.students << my_student
implicitly does a my_student.School = my_school
The same situation is extremely difficult to achive with static languages like C#.In general you do explicitly
mySchool.Students.Add(myStudent);
myStudent.School = mySchool;
Ruby on Rails versus Flex:
Now this can't be a comparison because Flex is for pure front end. And you can perfectly use Flex with Rails. Even there is a book for it. Flexible Rails. Some people call Flex+ Rails as the RIA Nirvana. I told you I like a componentized approach. Flex is perfect for that. And rails is very good at serializing the domain data back and forth to Flex. If you can tolarate a flash thingie running inside your application (which I can't!) this is a perfect way to go.
Others:
Wheather rails is a hype or not, it is a really milestone in web application programming. It inspired other web framework developers a lot. Python got Django and TurboGears, PHP got Cake and Symfony, ASP.NET got MonoRail and ASP.NET MVC. Unfortunately I am not involved with them so I can't really compare them.
Conclusion:
If you tried others and still not satisfied try rails. I am sure that you won't regret. And where do you start ? I personally start with the Agile book available on rails' web site. But there is a huge documentation & screen casts on web too. Good luck !
Thursday, June 19, 2008
Java swing developer's painful moments!
I've programmed swing for while when I was java programmer. And I admit it was quite painful for me. At those times, before group layout in netbeans 5 emerged, we were forced to use some silly java layouts. The reason for that was suppose to be the sake of cross platformity. I remember absolute coordinates were highly discouraged in swing world. Instead, all we had was those crappy layouts namely, spring, grid, gridbag, etc. I know some people implement their own layouts and some use things like JGoodies. But all I remember is a bad taste from swing. Now watch this clip.
Funny right ? Well when I watched that I saw my self in a way. I never understood why I have to suffer that much. Now let me show you something. You probably know about the Mono framework I mentioned earlier. The open source .net implementation. It also implemented Windows Forms so that it allows us to run windows forms applications on linux too. And all you need is mono and its windows forms packages. No wine nor nothing else extra needed: Here are some screenshots for NUnit and NClass running on linux:
Nunit above running on linuxNClass above running on linux.
The interesting thing is both applications are written with windows forms (and written for windows without considering cross platformity) and windows forms uses absolute position and docking approach. So I feel pity for the moments I suffered for swing. Thank you mono!!!
Funny right ? Well when I watched that I saw my self in a way. I never understood why I have to suffer that much. Now let me show you something. You probably know about the Mono framework I mentioned earlier. The open source .net implementation. It also implemented Windows Forms so that it allows us to run windows forms applications on linux too. And all you need is mono and its windows forms packages. No wine nor nothing else extra needed: Here are some screenshots for NUnit and NClass running on linux:
Nunit above running on linuxNClass above running on linux.
The interesting thing is both applications are written with windows forms (and written for windows without considering cross platformity) and windows forms uses absolute position and docking approach. So I feel pity for the moments I suffered for swing. Thank you mono!!!
Forkwind Part 4: Domain Driven Design and Record Driven Design
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!!
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!!
Real Human Face with 3D Flash
Now isn't this fantastic!!! Just move your mouse and it follows:
The original site is :http://motionportrait.com/
The original site is :http://motionportrait.com/
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!
Subscribe to:
Posts (Atom)