您是否使用代码生成工具(除了那些用于生成代理的工具和内置于visual studio的设计器)？
您生成的应用程序的哪些部分？
你经常推自己的发电机吗？如果是这样,你会写什么类型的生成器(asp模板,代码等).如果没有,你使用什么第三方工具？
我目前正在开发一些不同的项目,它们都使用自定义代码生成器来处理从生成数据库结构,业务实体,DAL和BLL的所有内容.我很好奇其他人的经历是用这些工具.
是的,但我们称他们为实习生.
我在哲学阵营中认为代码生成器是"错误的",因为它们表明应该成为语言的一部分.
但是编写编写代码的代码是实用程序员的道德规范的重要组成部分,并且在实践中,如果生成的代码默认隐藏,代码生成也很有效.无论你想要多么纯粹的哲学,语言永远不会像你想要解决的问题一样快速地发展.
我想到了在Visual Studio中构建Windows窗体时生成的代码.如果需要,您可以查看生成的代码,但最好不要这样做.然而,转向使用WPF的声明性语言是优越的,因为以编程方式操作声明性代码比命令式代码更清晰,更可靠.
他们应该使用LINQ-To-SQL类做同样的事情.对于只具有属性且没有自定义行为的类,它们需要声明性语言.它可能会使这些实体类更容易动态 - 在底层数据库架构发生更改时自动更改.
我们尝试使用CodeSmith为数据库中的所有表生成.NetTiers类,但遇到了两个问题:
.NetTiers很臃肿,生成的代码非常庞大.我认为代码生成工具太容易让人产生麻烦.
由于模式正在积极开发和修改,我们不得不重新生成很多,最终使得很难将所有内容保存在源代码控制中,因为所有文件都在重新生成和替换.我最终不确定生成的代码是否应该在源代码控制中.
代码生成的最佳位置应该是编译器或构建阶段,而不是设计阶段.在C#中使用匿名类型或方法时,编译器会动态执行代码生成.如果在设计阶段生成代码,则每次基础参数发生变化时都会产生一大块必须重新生成的东西.
并不是说我们在.net/web域工作,而是来自各种家庭设计语言的自制代码生成工具是我们开发工具链的重要组成部分.我们有两个主要的这样的工具(带有语法和解析器以及正式定义),以及一些基于m4和perl等宏构建的小工具.它们最终都生成了纯C,这是本机编译的.
在我的经验中,特定于域的语言是程序员生产力的关键工具之一,适用于任何大型软件.如果您正在构建诸如编译器,模拟器或其他非常复杂的软件,这些软件具有许多在基本语言中完全不支持的重复模式(通常意味着可移植的C,有时候是C++),那么代码生成工具就是您的选择.我将领域特定语言视为概括的下一步:首先将常见计算分解为函数(或子程序为历史),然后将常用函数分解为模板或泛型(如果有这样的工具可用),然后中断更加通用,并将代码重复为完整的自定义语言.
这一切都是为了减少您实际编写的代码量,并从编程过程中删除任何形式的繁琐重复和非增值代码.一旦模式重复,请应用特定于域的语言!
当我做经典的asp工作(大约2001年)时,我开始回滚我自己的生成器(数据访问,sprocs等).我慢慢转移到CodeSmith,因为它更容易处理.我仍然主要为我的.NET代码生成所有数据访问层类型的东西(包括sprocs).
几年前,我从宏代码生成(即CodeSmith)跳到微代码生成.
不同之处在于,使用CodeSmith,我为我的应用程序生成了大量代码,所有代码都是通用的.这对于边缘情况变得有问题,并且在更改模板的源(即表结构)时重新生成.我还遇到了一些案例,其中有很多我没有使用的携带代码,但是是从我的模板生成的.所有这些方法都有效吗？也许,也许不是.进入并清理生成的代码将是一项巨大的工作(即在相同的代码库上超过一年).
相比之下,微代码生成允许我在我想要的正确场景中生成我需要的类.我用来做这件事的主要工具是ReSharper.我这样做的方法是在编写生产代码之前编写单元测试.在这种情况下,ReSharper使用我的单元测试作为模板来自动生成生产代码的骨架.然后,这只是填补空白的问题.
对于数据访问,我不再生成任何东西.我发现一个好的O/RM取代了我以前在数据访问层(即NHibernate)中放置的所有东西.鉴于此,我将永远不会在我的生活中编写或生成另一个数据访问层(我拒绝).
另外,我还可以获得大型单元测试套件的好处
由于Fog Creek Software的内部语言Wasabi内置了编译时代码生成器,我们使用它们来自动创建映射到数据库表的实体类的内容.因此,我们可以写下:而不是用十几种不同的属性和方法编写类.
京公网安备 11010802040832号