By mswatcher
via geekswithblogs.net
Published: Mar 28 2008 / 04:04
When you are coding in a hurry, it is very tempting to write business logic in the first place that comes to mind, such as a button click handler in your UI code. However, for all but the simplest systems, such a practice leads very quickly to a system that is very difficult to work with, much less modify, because its business logic is scattered like the ash from an erupting volcano. So let's take a step back and see how you can develop an application more intelligently.
Comments
Kenneth Downs replied ago:
Good article. The domain model does not need to be as separated from the db as is often thought, but this does not detract from the value of the article.
cszrw replied ago:
Whats the point of the specialization of these sub types if the ui is not interested in them. If the ui is interested in them then it is probably going to be the only thing apart from the DB that is. So why have all this couple stuff in the middle. Why move complex relationships and operations that will likely have integrity constraint and consistency implications for the db away from the db and its associated developers.
If you are going to layer applications look for generality and agnostic data flows before you couple stuff together with strong types.
If you have a domain layer then you need a set of domain layer developers and any maintenance or change has to happen in three places instead of two. If the business logic is in SP in the db, the transport layers are agnostic (maybe multi channel) and the UI or end data users (may be users, other classes or systems) know about specializations that they are interested in then you have saved yourself a whole set of developers and and whole shedload of complexity and coupling.
Rob ,
Voters For This Link (9)
Voters Against This Link (3)