What are the pros and cons of using Visual Studio designer components for data [closed]_问答_开发者

Close开发者_如何学编程d. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this 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.

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:

Skill Matter are a training facility that run open session and loads of podcast you can watch
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
Martin Fowlers' blog for all thing DDD
Ayende's blog is great place for all things NHibernate
stackoverflow.com, this place rocks

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

I wouldn't even go so far as to say that the designer DB components are good for POCs or prototyping. Those components are in Visual Studio primarily as a sales pitch for the framework, so that Microsoft can say "wow, look how easy it is to create a data-driven application with .NET!" They should have been removed years ago, IMHO.

However, don't confuse the designer components with ADO.NET (i.e. DataTables, DataSets, DataReaders, DataAdapters etc.) itself. Since the app you've inherited was built around the designer components, that means that it was also fundamentally built around the ADO.NET components. You can (and should) get rid of the designer components, but you shouldn't necessarily get rid of ADO.NET as well.

I personally think you are definitely on the right track, BUT imho it really depends on what you already have and what the plans are for the future of the product.

I have seen production code that uses just as you are talking about and works fine, and is somewhat easily maintainable. There are even some great drop in modules from very large companies such as Telerik that fall into the same category of development that you are talking about.

I think what really is an important factor to your employer is: what can you use to get the job done in the fastest most efficient way. I would say that in general though, the "drag and drop" tools straight out of the box are not very good for long term enterprise level applications.

Here is an article by Charles Petzold that may provide more "expert" credential information for you.

http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html