请问用代码生成器生成的三层架构和手工建立的三层有什么区别？
今天经历让建一个三层框架出来，我就用动软代码生成器，生成了一个简单三层出来。但是经理说这个不行，自己建一个。
我感觉两种都是一样的？有什么区别呢非要手工建立一个？？？？
请各位架构大神给点建议吧

------解决方案--------------------
如果你手工建的和机器建的一样，那你真不行。管你三顿饭比交点电费贵多了。
------解决方案--------------------
kao ,一个框架那么容易写出来嘛

抽象数据层，你用sqlserver，那么你sqlserver继承抽象数据层，写自己的数据层，扩展sqlserver数据层

抽象逻辑层，sqlserver的逻辑层继承抽象逻辑层，写成自己的逻辑层

模型层，这个可以用工具生成

前两个你必须手动写好 ，然后在让工具生成才能用，直接用工具生成的，你在自己扩展，那不行，你每个项目都要扩展吗。

最后还要有自己的一个常用工具函数库。比如缓存，字符，类型转换，xml操作等，写到一个函数库里，用的时候直接调用
------解决方案--------------------
其实生成的还是能用的 我当初也用过动软代码生成器
但现在给我选择 我会选择codesmith 因为可以自己写模版 确定自己要生成什么代码~

如果你明白了三层的好处和如何搭建的 代码生成工具只是可以减少我们敲那种没营养的代码

如果你没有用过三层 现在也不了解 那么三层和代码生成工具都挺吓你的~
------解决方案--------------------
动软生成的三层，其实就是简单的数据访问层，业务逻辑，界面，说白了它生成的只是一个业务的传递，任何一个稍微复杂点的系统根本不适合使用哪种模式，简单的系统会觉得那个三层有点多余。一个系统架构的设计需要首先去了解业务需求。如果说任何系统我们都用动软的代码生成器，那么架构师就失业了。

我的建议是你先去了解一下你将要做的系统的需求。搞明白了再想想从技术的角度你该怎么处理，任何一个刚毕业的人做项目都会迷茫。一般都是从修改小的功能点开始入手然后逐步扩大可处理的范围，比如到一个模块，再到多个模块。所以有点惊讶你们经理的这个决定真实的意图是什么。
------解决方案--------------------
你必须要用代码生成器，codesmith,dsl T4 模板等。
如果十几个表，几十个表，都要写实体类，你估计会吐血的，


码生成器 开发框架，是解放程序员双手的工具，在你建立项目后，基本的搭建，都是框架，代码生成干的

最后逻辑开发，扩展才是你做的，就是生成逻辑层也是基本实现，比如实体获取，列表绑定，增删改查，这些基本操作都一样，不用一个个的写。

但是业务逻辑不是框架，代码生成器所能解决的，所以得靠程序员的大脑，思考，写出稳健，可靠，高效的商业业务逻辑。

你要想弄一个框架也不是一时半会，就能搞定的。你多查查资料三层的实现吧


------解决方案--------------------
代码生成需要先有通用解决方案的代码，然后才是有模板。生成的代码不是用来被改的，是用来被扩展的。有新的需求，要改也是改模版，甚至扩展模版。所以生成的代码与手写的代码，不存在谁好谁坏，因为生成代码的好坏是模版决定的，而模版就是手写的代码。
代码生成ORM，个人认为最佳实践是由实体类映射生成数据库，不是由数据库结构映射生成实体类。
很多人把代码生成与ORM划等号，其实ORM只是代码生成的一个小案例而已，也许因为ORM经常被提到。
只是说真的，这事不应该是现阶段的你做的，除非你经理只是个挂牌的。
------解决方案--------------------
楼主，看你这种情况，是因为基础缺乏，而这些基础是[程序如何设计、软件体系结构、设计模式、软件工程、...]

建议你在公司做项目的同时，自己也在家用C/C++或者Java写一些本地的小程序，顺便深入下软件工程、软件体系结构那些方面的知识。

楼主的困境在于对“设计”方面的知道的太少，而程序设计，最重要的就是“设计”，有良好的“设计”，才有良好的软件。编写只是其中一个必要的过程，仅仅是一个实现的过程。“设计”才是最根据的。

要学好“设计”，就需要大量学习计算机方面的知识，不管是搞WEB的还是本地的，都没有理由不学习计算机基础知识，这些知识有：“操作系统、编译原理、数据结构、软件工程、...”

不光是大量的知识，还要有自己的经验，经常写一些自己的软件，不是盲目写，而是有目的的写。在写之前设计好程序的结构，或者在网络上搜索已有的结构、方式。如果你坚持，那么每成功设计一个小程序，你就提升了一点经验。
------解决方案--------------------
各种生成器里面需要自己修改很多东西。。
实体类这样的如果你能确定不再修改数据库的话，能生成就生成吧。。
至于数据访问和业务逻辑还是要自己写的。。
------解决方案--------------------
生产方式落后的开发组织中,
程序员基本上都是在一遍一遍的实现相似的甚至相同的业务逻辑,
代码生成器生成的也就是这样类似的代码,
所以无论是复制粘贴还是自动生成,都没有基于"好的设计"去实现,


------解决方案--------------------

探讨

引用:
你必须要用代码生成器，codesmith,dsl T4 模板等。
如果十几个表，几十个表，都要写实体类，你估计会吐血的，


码生成器 开发框架，是解放程序员双手的工具，在你建立项目后，基本的搭建，都是框架，代码生成干的

如果让我设计,那些所谓的实体类根本就不存在,
10年前可能ORM还很流行,现在的技术手段已经能很好的支持MVC设计了,
能很好的……

------解决方案--------------------

探讨

而对象就必须要用到实体，实体就必须要存在有Model层，Model层作为BLL层和DAL层通信的工具存在。

------解决方案--------------------
楼主,首先我是人不是神,只有上帝才是独一的神.

建议你看看Moon.Orm可以解决你上面的问题.
----但凡众多的智慧都是及其简单的,但不为人所知.这也是Moon.ORM的主要特色:大道至简.

1.高性能是Moon.ORM优势之一,也是我架构它的主要目的之一,我想如今没有其他的ORM(非纯ADO.Net方式的性能可以与Moon相比,你可以下载3.9试试便知),我已经将它的性能提升到了极致.如以前我说的那样,是为了弥补项目中遇到的性能问题而设计.可以说对于整个框架数据 处理上采用了纯的ADO.NET进行封装同时结合了EMIT达到快速生成实体的目的(当然到时候也可以用4.0的代码生成器完成纯ADO.NET的开 发).我不得不承认linq和lambda语句带来的优雅,但同时我们需要承认linq的局限性.或许有人说可以通过手段进行一些弥补,如有人以提高 linq性能来写文章一样,但我们需要承认两个事实,每次对linq的系统识别后才能进行优化,也就是说,linq的天性决定有性能损失.再次linq不 是银弹,因为负责的场合linq几乎是做不到的,何况linq生成的sql不一定是你真正要的.(注意:我不是敌对linq,而是说实话,正如曾说:实际开发中没有银弹,只有平衡点,适合需求能解决实际情况的架构那就够了)而且我也没有必要再去写一个框架,做一个类似Nhibernate,或者实体框架的东西.做东西我一直认为需要做一个能有自我的特色和优势.