|
|
|
|
|
by mrtron
6781 days ago
|
|
It shows a lack of nothing. What DAL is a code generator that writes large quantities of code based on your 'models'? It simply provides a better or easier interface. Here is what I meant:
When a commercial application becomes popular to generate large amounts of code to do a small amount of work, like some CRUD, I personally feel that shows a flaw in the fundamental way the language works. The language should either be able to offer you a better way of doing it yourself, or writing a small framework for yourself. If neither of these are viable options, I would consider that a serious knock against the language. |
|
Here's the problem with what you said -- the word "code". It's not defined. In any kind of large environment, my application uses all kinds of compiled code. So what if I push a button or flick a switch to use another hunk of code that I don't have to write or test? Is using System.Io somehow "better" than say, having an automated macro that generates IO based on some user preference?
Yes -- I would agree that if I have to write and maintain a large amount of code to do easy stuff we've got a problem somewhere. But if my platform is powerful enough to allow me to use multiple Data Access paradigms without any work on my part? Who cares if when I flip the switch the code is generated and compiled or if it was generated and compiled last week or last year?
Take a look at something like CodeSmith. Here's a tool that uses .NET to write programs for .NET. Now yes, you can generate a lot of code that way -- if you want to look at it like that. You can also go and get open source libraries and templates that will generate tested, proven, full-featured libraries based on your particular situation. Isn't that a much better thing than simply having one paradigm that everybody has to shoe-horn their work into?