What are the pros and cons of using Visual Studio designer components for data [closed]

Question

I'm inheriting a bunch of programs at work where the original author used Microsoft Visual Studio's data components (where a dataset, data adaptor, etc) are creating inside the design environment (from the toolbox or using wizards). This yields some semi-tailored (specialized for the data) classes, and also puts the SQL code into designer generated classes.

This is not how I'm used to doing things (I've always preferred to either unambiguously have a dataset, or create my own specialized class to hold the data and hide the complexity of the underlying data layer).

Does anyone have some good insight or links discussing the pros and cons of using Visual Studio data components?

(A side note, the original author also didn't comment very thoroughly and wrote, for my tastes, a bit too much "clever" code that is not easily interpreted, so I'm not inclined to think he knows any better than I.)

I suppose another way of asking is this: Does using the data designer components result in code that is "following best practices" and is maintainable, etc? It doesn't seem so to me, but I'm looking for input from experts.

[EDIT: Added some more context for clarification of intent]

If I'm right (and it looks like I am) about using designer components really being best suited for prototypes, etc, then I'm going to have to go have some tough conversations with the original developers and my manager. So I'd like to add more emphasis on "links discussing pros and cons" part of my question... I'm looking for something substantial I can use to support my claims that this style of development / code isn't the most appropriate for production use... Thanks.

Answer 1

In general visual components are for throwaway applications, POC's and spike applications, i.e. prototyping. This is for a couple of reasons; they are very quick to get together but a complete nightmare to maintain. I'm unsure of the size of your application but if it were me I would be arguing that in it's current form the cost of ownership will increase with time and therefore would look to more of a DDD style of development. Bin the data layer and replace it with a good solid ORM; NHibernate(preferred) or Entity Framework 4 (easier to get into). Drop that 'clever code' and start using the Kiss, Yagni, dry mantra. It might be difficult to get them to see the light but once it starts costing less they'll love you for it ;)

If you want some more reading in this area look at the following:

1. Skill Matter are a training facility that run open session and loads of podcast you can watch
2. A good book for both Dev's and managers to read is Ship IT, it looks at good project practices. As does anything on the pragmatic bookshelf
3. Martin Fowlers' blog for all thing DDD
4. Ayende's blog is great place for all things NHibernate
5. stackoverflow.com, this place rocks

Answer 2

VS data components purpose is rapid application development. From this point of view you can see its pros and cons:

pros: fast development, do not require much coding and knowledge. Good for small applications which will not be changed in a future.

cons: breaks Layer application design logic (add here all pros of such design) combining all in one file. As a result almost impossible to replace datasource dynamically. Makes more complicated large application support. DI, TDD - it something mysterious using it.

Actually it's a very wide question. I'd recommend to read more about N-tier application development and Test Driven Development

Hope this help