Am going to develop a website which has to handle different kind of users and there is an option to enter the different kind of data(real estate information). Each
real estate information can be considered as an object .Recently I read about design patterns. How to determine whether i need to use a design pattern or not in and which one I need .
Design Patterns are like programming languages:
They don't solve your problem by themselves, neither they guaranty that your design decisions are an appropriate solution for the problem. Stick with a design pattern you like, and most important, understand.
Another fault that seems to happen very often is that people pick a design pattern and then later start to abandon it, and switch to another one - Which leads to crapcode and mass confusion, sooner or later.
I found a nice page summing up all of the important aspects of design patterns:
Patterns are not the panacea of program design. They do not replace traditional object-oriented analysis techniques like CRC cards or use-case modeling. To use an architectural analogy, analysis lets you determine that your house needs 200 amps of electricity. Patterns let you determine how the wiring will be installed.
Patterns do help you think about the problems you may encounter while designing a system. Therefore, a generic, pattern-based solution is often more robust than a solution designed by one individual to solve a specific problem.
Given the number of design patterns in common use (as well as many more being invented and discovered almost daily) it can sometimes be hard to choose the pattern that suits your needs.
The first thing you should decide is whether the problem is fundamentally creational, structural, or behavioral. Some problems, of course, have aspects of two or even three, and may require you to mix and match patterns.
A design pattern is just a fancy term for a particular architecture that some experienced and clever people have determined is good for a particular use case. If your use case is one that has been done many times and has well defined patterns for it, then you should consider modelling your own design on one of those patterns. They are one step more specific than architectural guidelines like layering, dependency isolation, boundary interfaces etc.
Your application sounds like a fairly typical 3 tier web application and if you're starting from scratch in a .Net environment then you will probably want to use ASP.net MVC with Entity Framework or a similar ERM (e.g. NHibernate). MVC is a well specified and well tested design pattern that generally works well for that kind of application.
The important thing to remember about patterns is that they are not a prescriptive set of instructions, they're guidelines and example designs for particular scenarios. If you don't want to do quite the same thing that they did, it's natural that your design might want to be slightly different. What patterns give you is a set of initial starting points that you can use to inform your design process.
Just write the best code you can; either it will match an existing Pattern or it won't, no big deal.
Naming Patterns isn't really for a developer's own use; it's for developers to easily communicate ideas amongst themselves.
Think of it like ordering a pizza; the pizza shop may have a list of "named" styles, like "veggie", "meat lovers", "hawaiian", etc. but you are also free to specify toppings as you please. It may be that the set of toppings you choose happens to match one of the named styles that you aren't familiar with and the clerk may then tell you that you could just order the "greek" next time. Saying "greek" the next time will save time and may reduce confusion, but does not carry any more information than you provided the first time. Likewise, if you make a pizza at home, you wuoldn't tell yourself that you want to make a "greek" pizza, you'd would just make a pizza any way you want, and it may turn out that it matches the "greek" pizza that that pizza place offers.
As a side note, when I was first introduced to "hawaiian" pizza it had ham and pineapple. When I ordered "hawiian" pizza from a different place, the clerk asked, "well what exactly does 'hawaiian' pizza mean to you?"
Also bear in mind that not all developers understand Design Patterns exactly the same. The "Gang of Four" book is the definitive reference. Also remember that just because the Pattern has a name, it isn't necessarily a good idea.
Delegates and (data) binding are useful in different circumstances.
Although, both can be used to change property values at runtime, multicast delegates are useful when you want to invoke multiple operations (rather than bind data) at runtime. Binding on the other hand is useful to directly set the values of properties at runtime. Binding a property to a value will not help you execute methods.