应该说，SQL语句，真的心很强大。但是我一直都觉得比较奇怪。为什么要用SQL语句作为介质。
而不是直接暴露数据库中的一些方法给我们调用。SQL的好处：
强大，灵活，传输量也不是很大。但是也有坏处：
解析SQL。
SQL标准不统一。
每次用ado.net 都觉得很烦。
要写很多SQL，要写很多方法...我几次尝试，想把SQL语句封装到类里面，然后通过使用反射，直接接受对象，然后自动遍历对象，并实现怎删改查好处是不需要维护SQL语句和数据操作类了
只需要维护对象和，逻辑代码。但，一些复杂的逻辑还是一样要SQL。相当麻烦....
我觉得，要想提高生产效率 真的有必要，出现一个统一的中间层。
用方法替代掉所有的SQL语句。有没有童鞋有什么好的设计思路
——————————————————————————————————最近出现了，Repository模式，晕啊，我觉得最近出现的IOC，领域驱动，还有之前的ORM，等等都是因为SQL，SQL语句，关系数据库。SQL语句这个折磨了成千上万程序员的东西，什么时候才是该退出历史舞台的时候。
各位 不妨 讨论讨论，这方面的问题
sql数据库iocormNOSQL
而不是直接暴露数据库中的一些方法给我们调用。SQL的好处：
强大，灵活，传输量也不是很大。但是也有坏处：
解析SQL。
SQL标准不统一。
每次用ado.net 都觉得很烦。
要写很多SQL，要写很多方法...我几次尝试，想把SQL语句封装到类里面，然后通过使用反射，直接接受对象，然后自动遍历对象，并实现怎删改查好处是不需要维护SQL语句和数据操作类了
只需要维护对象和，逻辑代码。但，一些复杂的逻辑还是一样要SQL。相当麻烦....
我觉得，要想提高生产效率 真的有必要，出现一个统一的中间层。
用方法替代掉所有的SQL语句。有没有童鞋有什么好的设计思路
——————————————————————————————————最近出现了，Repository模式，晕啊，我觉得最近出现的IOC，领域驱动，还有之前的ORM，等等都是因为SQL，SQL语句，关系数据库。SQL语句这个折磨了成千上万程序员的东西，什么时候才是该退出历史舞台的时候。
各位 不妨 讨论讨论，这方面的问题
sql数据库iocormNOSQL
解决方案 »
- treeview 问题
- 请问，关于窗口焦点
- socket服务器代码怎么实现自动监听？
- c# Regex.Match
- ExecuteNonQuery();并非所有的字段都已绑定
- 如何在vs2003的机器上装一个.net 2.0 framework，就可以运行vs2005的exe吗？
- 各位大侠，小弟求救，如何在C#中实现将一个文件夹及所有的内容复制到另外的一个文件夹里。谢谢了！
- HttpContext.Current.Server.MapPath 在应用程序中为什么不能正确使用?
- 求教，请问为什么在导完Excel并退出后，还是存在那个Excel进程的？
- dataview中选择多行的问题
- 现在开发软件用哪个版本的.net呢？
- 输出字符串的问题
里面充满了Linq之类的。
神啊，似乎那似乎只是把SQL放到了C#代码里面。
而且EF也不太灵活，代码量也没减少多少。
这个产品或许是一个开源的，没有SQL语句的，面向对象的数据库？
抛砖引玉。等待大牛出现。
拼sql文还是老老实实的写吧，只要把sqlhelper这类的工具用熟了，套一套就行了。
另外一点，ORM可以为界面提供树状视图(你可以Answer.Question.User...)，不是二维表格。如果要抛弃SQL语句，就不能以SQL功能为出发点来设计ORM，否则难以摆脱所谓的复杂的SQL语句。
比如http://www.51nod.com/today.html#!type=all，实践证明没有SQL语句的项目做得更舒心。
欢迎关注开源项目fastCSharp，将支持.NET2.0的lambda解析SQL，IDE最低支持vs2010。
好像都能解决问题
LINQ算不算呢？
我自己没有用过LINQ。
正如网站前端要会html js css，数据库要会sql很奇怪吗？反而是希望使用数据库而又不想写sql的想法更奇怪。
有的啊，OCI就是oracle提供的开发接口。
10年前我们做项目时就是先用oci封装数据库操作，具体的表一般会定义成类，所有数据库操作都封装成底层方法，复杂的业务逻辑都是一般是通过方法调用来实现的。
从人力资源看，会写程序的多，但写得好sql的人少，所以项目中要避免维护复杂SQL或存储过程.
直接开放sock接口就可以了 干嘛还要绕远路去拼sql语句再查询
SQL还是数据库交互的核心，有些时候，有些东西用纯原生的SQL是有它的道理。
两者兼顾，发挥各自的优势才是王道！