I want to make a perfect custom DAL (data abstraction layer) class to use with all my projects.
我想制作一个完美的自定义DAL(数据抽象层)类,用于我的所有项目。
I've searched the internet and found some samples for this but I never know which is the best approach.
我搜索过互联网并找到了一些样本,但我不知道哪种方法最好。
Is it to make [Attributes]
? Or use <Generics>
or something else?
是要制作[属性]吗?或者使用
So please just give me a head line and I'll go on from there.
所以,请给我一个头条,我会从那里继续。
Thanks again and forgive my language.
再次感谢并原谅我的语言。
9 个解决方案
#1
Best approach is:
最好的方法是:
Don't do it yourself unless its for an academic research project or you intend to build a business shipping ORMs.
除非是为了学术研究项目或者您打算建立一个运输ORM的商业,否则不要自己动手。
Try out the dozens of existing ORM solutions first. (Entity framework, subsonic, nhibernate etc etc...). They all have their quirks and limitations mixed in with tons of awesomeness.
首先尝试几十个现有的ORM解决方案。 (实体框架,亚音速,nhibernate等等......)。他们都有他们的怪癖和限制混合在一起,令人敬畏。
ORMs are incredibly hard to get right and a huge undertaking.
ORM非常难以正确完成并且是一项艰巨的任务。
Slightly related and on the money: http://wekeroad.com/2009/06/11/youre-not-your-data-access/
与钱有点关联:http://wekeroad.com/2009/06/11/youre-not-your-data-access/
#2
Just make sure you:
请确保你:
- Always use stored procedures
- Never use stored procedures
- Sometimes use stored procedures
- Use nHibernate
- Use SubSonic
- Use Entity Framework
- Write your own
- Never write you own
- Use POCO
- Use ActiveRecord
- Use IRepository
- Always do what Fowler says
- Never do what Fowler says
- Don't use Linq to SQL, it's dead
- Use Linq to SQL, it's no longer dead
始终使用存储过程
切勿使用存储过程
有时使用存储过程
使用实体框架
写你自己的
永远不要写你自己
永远做福勒所说的
永远不要做福勒所说的
不要使用Linq来SQL,它已经死了
使用Linq to SQL,它不再死了
Do all that and you will be fine.
做这一切,你会没事的。
#3
I can recommend you to read this article first. And take a look at EnterPrise Library's Data Access Application Block.
我建议你先阅读这篇文章。并查看EnterPrise Library的数据访问应用程序块。
#4
If you are a starter I would recommend use of SubSonic (more so if you are on web development).
如果您是初学者,我建议使用SubSonic(如果您正在进行Web开发,则更多)。
#5
as also one mentioned, don't try to implement a ORM tool yourself, there are a lot of them freely available. But a DAL isn't a ORM tool, the ORM tool will be used within your DAL. The DAL is just for hiding the data access logic from the rest of your app in order to have a more maintainable solution. In the end you could also have normal SQL statements i. your DAO class. What you should pay attention at when creating your DAL is to decouple it as much as possible from the rest of the app/other layers. This can be achieved by coding against interfaces and by using dependency injection. Spring is a great help here (given you program in Java). Beside that, there is no big magic on building such a layer.
同样提到的一点,不要试图自己实现ORM工具,有很多免费提供。但是DAL不是ORM工具,ORM工具将在您的DAL中使用。 DAL仅用于从应用程序的其余部分隐藏数据访问逻辑,以便拥有更易于维护的解决方案。最后,您还可以拥有正常的SQL语句。你的DAO课程。创建DAL时应注意的是尽可能将其与app / other层的其余部分分离。这可以通过对接口进行编码并使用依赖注入来实现。 Spring在这里是一个很好的帮助(给你Java程序)。除此之外,构建这样一层并没有什么大的魔力。
#6
Trying to create the ulimate, best, perfect DAL seems a bit crazy - there are so many different application scenarios with different and competing requirements and needs that I don't believe anyone can come up with THE ONE ultimate DAL.
尝试创建ulimate,最好,最完美的DAL似乎有点疯狂 - 有许多不同的应用场景具有不同的竞争要求和需求,我不相信任何人都能想出一个终极DAL。
You need to check out some of the existing ORM tools, get to know one or two of them, know their strengths and possibly drawbacks, and then be able to pick the best one for every given situation. I doubt it'll always be the same.....
您需要查看一些现有的ORM工具,了解其中的一个或两个,了解它们的优势和可能的缺点,然后能够针对每种情况选择最佳的ORM工具。我怀疑它总是一样的.....
SubSonic is great for smaller, nimbler projects - as is Linq-to-SQL, as long as you use SQL Server as your backend. If you need more enterprise power, you should look at NHibernate, ADO.NET Entity Framework, or other bigger, more capable players (which are just too complex and ill suited for a small, simple scenario).
SubSonic非常适合更小,更灵活的项目 - 就像Linq-to-SQL一样,只要您使用SQL Server作为后端即可。如果你需要更多的企业能力,你应该看看NHibernate,ADO.NET实体框架,或其他更大,更强大的玩家(这些太复杂,不适合小型,简单的场景)。
I don't think there's THE perfect way to create a DAL - learn what's available, learn how to choose the one best suited to your current need, and don't reinvent yourself - use what's available out there!
我不认为有创造DAL的完美方式 - 了解可用的东西,学习如何选择最适合您当前需求的东西,不要重塑自己 - 使用那里可用的东西!
Marc
#8
Definitely don't write your own persistence manager. You should use an Object-Relational Mapper (ORM) if you want to start from a class structure and have the ORM generate the SQL table structures for you, or use an SQL Mapper if you want to start from SQL tables and want to have your classes represent table rows.
绝对不要编写自己的持久性管理器。如果要从类结构开始并让ORM为您生成SQL表结构,则应使用对象关系映射器(ORM),或者如果要从SQL表开始并希望使用SQL表,则应使用SQL Mapper类表示表行。
I've had great experience using the iBatis SQL Mapper, and a lot of people like Hibernate for an ORM (though there's a learning curve).
我有很好的使用iBatis SQL Mapper的经验,很多人喜欢Hibernate用于ORM(虽然有学习曲线)。
Martin Fowler describes several good approaches for writing data access layers in Patterns of Enterprise Application Architecture (here's a catalog).
Martin Fowler描述了在企业应用程序架构模式中编写数据访问层的几种好方法(这是一个目录)。
For instance, iBatis for .NET uses Fowler's Table Data Gateway pattern. In iBatis you specify Table Data Gateway objects in XML. Each Gateway typically governs access to one SQL table, although you can do multi-table operations too. A Gateway is composed of SQL statements, each wrapped in a bit of XML. Each SELECT returns one or more row objects, which are just sets of attributes plus getter and setter methods (in .NET these are called POCOs or PONOs, Plain Old C# Objects or Plain Old .NET Objects.). Each INSERT or UPDATE takes a POCO as its input. This seemed pretty intuitive, and not too hard to learn.
例如,iBatis for .NET使用Fowler的表数据网关模式。在iBatis中,您可以在XML中指定Table Data Gateway对象。尽管您也可以执行多表操作,但每个网关通常会管理对一个SQL表的访问。网关由SQL语句组成,每个语句都包含一些XML。每个SELECT都返回一个或多个行对象,这些行对象只是属性集以及getter和setter方法(在.NET中,这些对象称为POCO或PONO,Plain Old C#Objects或Plain Old .NET Objects。)。每个INSERT或UPDATE都以POCO作为输入。这看起来非常直观,而且不太难学。
#9
Linq to SQL is the best solution or you can try da easiest solution http://fluentado.codeplex.com/
Linq to SQL是最好的解决方案,或者您可以尝试最简单的解决方案http://fluentado.codeplex.com/
#1
Best approach is:
最好的方法是:
Don't do it yourself unless its for an academic research project or you intend to build a business shipping ORMs.
除非是为了学术研究项目或者您打算建立一个运输ORM的商业,否则不要自己动手。
Try out the dozens of existing ORM solutions first. (Entity framework, subsonic, nhibernate etc etc...). They all have their quirks and limitations mixed in with tons of awesomeness.
首先尝试几十个现有的ORM解决方案。 (实体框架,亚音速,nhibernate等等......)。他们都有他们的怪癖和限制混合在一起,令人敬畏。
ORMs are incredibly hard to get right and a huge undertaking.
ORM非常难以正确完成并且是一项艰巨的任务。
Slightly related and on the money: http://wekeroad.com/2009/06/11/youre-not-your-data-access/
与钱有点关联:http://wekeroad.com/2009/06/11/youre-not-your-data-access/
#2
Just make sure you:
请确保你:
- Always use stored procedures
- Never use stored procedures
- Sometimes use stored procedures
- Use nHibernate
- Use SubSonic
- Use Entity Framework
- Write your own
- Never write you own
- Use POCO
- Use ActiveRecord
- Use IRepository
- Always do what Fowler says
- Never do what Fowler says
- Don't use Linq to SQL, it's dead
- Use Linq to SQL, it's no longer dead
始终使用存储过程
切勿使用存储过程
有时使用存储过程
使用实体框架
写你自己的
永远不要写你自己
永远做福勒所说的
永远不要做福勒所说的
不要使用Linq来SQL,它已经死了
使用Linq to SQL,它不再死了
Do all that and you will be fine.
做这一切,你会没事的。
#3
I can recommend you to read this article first. And take a look at EnterPrise Library's Data Access Application Block.
我建议你先阅读这篇文章。并查看EnterPrise Library的数据访问应用程序块。
#4
If you are a starter I would recommend use of SubSonic (more so if you are on web development).
如果您是初学者,我建议使用SubSonic(如果您正在进行Web开发,则更多)。
#5
as also one mentioned, don't try to implement a ORM tool yourself, there are a lot of them freely available. But a DAL isn't a ORM tool, the ORM tool will be used within your DAL. The DAL is just for hiding the data access logic from the rest of your app in order to have a more maintainable solution. In the end you could also have normal SQL statements i. your DAO class. What you should pay attention at when creating your DAL is to decouple it as much as possible from the rest of the app/other layers. This can be achieved by coding against interfaces and by using dependency injection. Spring is a great help here (given you program in Java). Beside that, there is no big magic on building such a layer.
同样提到的一点,不要试图自己实现ORM工具,有很多免费提供。但是DAL不是ORM工具,ORM工具将在您的DAL中使用。 DAL仅用于从应用程序的其余部分隐藏数据访问逻辑,以便拥有更易于维护的解决方案。最后,您还可以拥有正常的SQL语句。你的DAO课程。创建DAL时应注意的是尽可能将其与app / other层的其余部分分离。这可以通过对接口进行编码并使用依赖注入来实现。 Spring在这里是一个很好的帮助(给你Java程序)。除此之外,构建这样一层并没有什么大的魔力。
#6
Trying to create the ulimate, best, perfect DAL seems a bit crazy - there are so many different application scenarios with different and competing requirements and needs that I don't believe anyone can come up with THE ONE ultimate DAL.
尝试创建ulimate,最好,最完美的DAL似乎有点疯狂 - 有许多不同的应用场景具有不同的竞争要求和需求,我不相信任何人都能想出一个终极DAL。
You need to check out some of the existing ORM tools, get to know one or two of them, know their strengths and possibly drawbacks, and then be able to pick the best one for every given situation. I doubt it'll always be the same.....
您需要查看一些现有的ORM工具,了解其中的一个或两个,了解它们的优势和可能的缺点,然后能够针对每种情况选择最佳的ORM工具。我怀疑它总是一样的.....
SubSonic is great for smaller, nimbler projects - as is Linq-to-SQL, as long as you use SQL Server as your backend. If you need more enterprise power, you should look at NHibernate, ADO.NET Entity Framework, or other bigger, more capable players (which are just too complex and ill suited for a small, simple scenario).
SubSonic非常适合更小,更灵活的项目 - 就像Linq-to-SQL一样,只要您使用SQL Server作为后端即可。如果你需要更多的企业能力,你应该看看NHibernate,ADO.NET实体框架,或其他更大,更强大的玩家(这些太复杂,不适合小型,简单的场景)。
I don't think there's THE perfect way to create a DAL - learn what's available, learn how to choose the one best suited to your current need, and don't reinvent yourself - use what's available out there!
我不认为有创造DAL的完美方式 - 了解可用的东西,学习如何选择最适合您当前需求的东西,不要重塑自己 - 使用那里可用的东西!
Marc
#7
Please read Data Access Layer Design Considerations
请阅读数据访问层设计注意事项
#8
Definitely don't write your own persistence manager. You should use an Object-Relational Mapper (ORM) if you want to start from a class structure and have the ORM generate the SQL table structures for you, or use an SQL Mapper if you want to start from SQL tables and want to have your classes represent table rows.
绝对不要编写自己的持久性管理器。如果要从类结构开始并让ORM为您生成SQL表结构,则应使用对象关系映射器(ORM),或者如果要从SQL表开始并希望使用SQL表,则应使用SQL Mapper类表示表行。
I've had great experience using the iBatis SQL Mapper, and a lot of people like Hibernate for an ORM (though there's a learning curve).
我有很好的使用iBatis SQL Mapper的经验,很多人喜欢Hibernate用于ORM(虽然有学习曲线)。
Martin Fowler describes several good approaches for writing data access layers in Patterns of Enterprise Application Architecture (here's a catalog).
Martin Fowler描述了在企业应用程序架构模式中编写数据访问层的几种好方法(这是一个目录)。
For instance, iBatis for .NET uses Fowler's Table Data Gateway pattern. In iBatis you specify Table Data Gateway objects in XML. Each Gateway typically governs access to one SQL table, although you can do multi-table operations too. A Gateway is composed of SQL statements, each wrapped in a bit of XML. Each SELECT returns one or more row objects, which are just sets of attributes plus getter and setter methods (in .NET these are called POCOs or PONOs, Plain Old C# Objects or Plain Old .NET Objects.). Each INSERT or UPDATE takes a POCO as its input. This seemed pretty intuitive, and not too hard to learn.
例如,iBatis for .NET使用Fowler的表数据网关模式。在iBatis中,您可以在XML中指定Table Data Gateway对象。尽管您也可以执行多表操作,但每个网关通常会管理对一个SQL表的访问。网关由SQL语句组成,每个语句都包含一些XML。每个SELECT都返回一个或多个行对象,这些行对象只是属性集以及getter和setter方法(在.NET中,这些对象称为POCO或PONO,Plain Old C#Objects或Plain Old .NET Objects。)。每个INSERT或UPDATE都以POCO作为输入。这看起来非常直观,而且不太难学。
#9
Linq to SQL is the best solution or you can try da easiest solution http://fluentado.codeplex.com/
Linq to SQL是最好的解决方案,或者您可以尝试最简单的解决方案http://fluentado.codeplex.com/