In part I, I covered datasource controls and two way databinding. In part II, I went into how to use table adapters for handling CRUD operations with two way binding. Today I want to explain when it makes sense to use these features.
It is important to keep in mind that any technology, feature or pattern will only be useful in a certain context. Two way databinding is a good fit for single table editing scenarios in applications that will not get heavy user loads. For more complex joined data you have to write code and it forces you into a very data centric and hard to test design. For applications that have complex editing scenarios you are often better off handling the GridView events directly. If you are designing a system with lots of business rules, you should probably using a rich domain model. I intend to write a post about using domain driven design patterns soon.
By the same token, there are other options for handling data presentation. Depending on you needs, you might want to consider using a commercial grid control like Telerik, Infragistics or Ext js. Many of these controls will handle updating your datasource object for you, which gives you more freedom in the design of your data access strategy.
If you found this series useful, saw a mistake or have any questions please let me know. I am always interested in feedback, so feel free to leave me a comment.
No comments:
Post a Comment