Is 3 Layered Architecture = MVC

Very nice discussion is going on this thread.

http://forums.asp.net/thread/1379168.aspx
At first after reading the post, I also got confused by striking similarities between two patterns thought one is design pattern other one is application pattern.
Survic has written a nice post on confusion regarding MVC.

This is one of best articulated posts that I have come across on this topic.


If you don’t understand confusion about MVC then read

First there are two documented versions of MVC
http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html

Here is sample of discussion on MVC and ASP.Net in which I took part
http://forums.asp.net/2/1249964/ShowThread.aspx


If you thought that this is enough then there is a MVP pattern.

Example of
http://codebetter.com/blogs/jeremy.miller/archive/2006/07/11/147305.aspx

After that Martin Fowler splits MVP into two parts to clear confusion (But now I am more confused)
http://geekswithblogs.net/billy/archive/2006/07/20/85815.aspx
http://martinfowler.com/eaaDev/PassiveScreen.html
http://martinfowler.com/eaaDev/SupervisingPresenter.html



I always use MVC as GUI or WEB based design pattern.
MVC is a design pattern for Interactive Interfaces.(LudovicoVan corrected me)
MVC in web context is more geared towards streaming HTML to different devices that understand HTML while 3 layer architecture is independent of any technology.
http://www.martinfowler.com/eaaCatalog/
http://www.martinfowler.com/eaaCatalog/modelViewController.html

One comment was that we should implement MVC in every layer of application.
I think that I know what the poster is implying.
Generally I believe in understanding the intent of pattern and implementing it my way that suits my project. But at the same time, we have to maintain some essence of design pattern for clear communication. While I understand what the poster is implying, I think that are specific patterns (factory,fascade,process layer,Aggregation etc) to describe the patterns applicable to good enterprise distributed computing needs.

Note: I am going to revisit this post

Showing Chinese or Japanese Characters in Charting / Graphing Tools

I was evaluating third party Charting Controls for our application. Somehow I was not able to show Chinese/Japanese characters properly on my machine. I was wondering whether it is problem with third party tools or my code. Finally after working with vendors, I found out problem was with my machine.
I am documenting this in my blog just in cause someone needs this info.

It is possible to show Chinese/Japanese characters in most of the charting tools. The only thing you need to do is have the Asian language pack installed. To do this; go to control panel -> Regional and Language Options then click on the language tab. From here, check the “install files for East Asian languages”. This will allow you to view Chinese on your machine. Once this is installed, all you need to do paste the text directly into the fields in the chart and it will show up properly.

Domain Driven Design based on Entity Model vs E/R Model

Continued from
http://vikasnetdev.blogspot.com/2006/07/domain-driven-design-vs-data-driven.html

Survic said
“I agree with you about the size of projects; but deep in my heart, I also believe that all larger business projects can be split into smaller projects, so, I do not believe “TDD with mocks and DDD without data” is good for anything -- I will keep an open mind though”


Hi Survic,
Thanks for pointing to Scott W. Ambler.’s book ‘The Object Primer’. It helped me to write this post. That is what I wanted to articulate in first place
First thing nobody is underestimating the importance of Data in Domain Driven Design. But there are following problems or realities in Enterprise Data Design (Scott calls Legacy Database design but DBAs continue to employ for consistency purpose)

1. A single data field is use for several purposes.
2. The purpose of a data field is determined by the value of one or more other columns.
3. Inconsistent values are stored in a single data field.
4. There is inconsistent/incorrect data formatting within a column
5. Some data values are missing with in a data field
6. One or more data fields that require do not exist.
7. Additional data fields that your application will need to support if it uses the legacy data exist
8. Multiple source exist for the same data and it is not clear which one to use
9. Important entities, attributes and relationship are hidden and floating in text fields
10. Data values can stray from their field descriptions and business rules.
11. Various key strategies are used to identify the same type of entity
12. You require a relationship between data records that is not supported by legacy data.
13. One attribute is stored in several fields.
14. Special characters within a data field are inconsistently used.
15. Different data types are used for similar columns.
16. The legacy data do not contain sufficient detail.
17. The legacy data contain too much data.
18. The legacy data are read-only, yet you require update access.
19. The timeliness of data varies from what you require
20. The default value used by a legacy application does not reflect the default value required by your system.
21. Different representations of the data exist.
22. The naming conventions used are difficult to understand

As per my experience with DBAs in past,Some decisions may be right in their own way. They are more concerned about efficient storage of data; need to be consistent with existing databases (what Scott calls legacy) and future extensibility at data storage level.

Some of above factors limit the database design diagram to be used as effective communication tool with all stakeholders. We need a abstraction above database which hide these complexities and communicate more clearly Problem Domain/System Blueprints to users.

This is where come entity classes’ diagrams (Since we both agree on importance of process classes diagrams, activity diagrams, Sequence diagrams etc.) which can hide all above mentioned storage details from system users. It will help the programmer to nail down the requirement and prepare the blueprints with out waiting for database design to be over. Once requirements are completely nailed, data storage/retrieval is more implementation details.

This debate is similar to XML Hell debate. Nobody is arguing against the importance of XML but we need an abstraction/Graphical tools to hide its rawness as discussed in the following mail
http://vikasnetdev.blogspot.com/2006/06/xml-hell.html

Reference:
The Object Primer – By Scott W. Ambler

Domain Driven Design-- My Rating 3-4/5 -- Currently Reading

This book will influence one to employ Domain Driven Methodology even in a pure Waterfall or fixed bid project. You will not like to be caught with out a Domain blueprint in Design phase after reading first five chapters book and will know the importance of Ubiquitous Language.

My criticism of book is that if you are well-verse in design patterns,Analysis patterns ,OOP concepts that book discusses, you may find little value in chapter 6 - 13. Authors should have shortened them into two or three chapters.

If you are new to Application and Design Patterns,Analysis Patterns and OOP , you will find this book more useful.
I am glad that I read it and it is over. (read 60%). I have to still read Chapter 14-17. May be some other time.