I use ASP.NET with a informix database.
I use a set of written classes to handle the connections, the CRUD operations, transactions, etc....
Now, I feel these classes are not the best choice, less performance,take a lot of time and have many drawbacks.
I want to use an ORM, but I don't know how to choose the one which suits my web applications (ASP.NET, Informix).
Please help to select the convenient ORM.
I'm confused among nHibernate, Entity Framework, LINQ To SQL, and the Open Access (Telerik Component).
Note: I will use Visual Studio 2012 so I want the recent comparison.
I'd really suggest Entity Framework, as it is the native framework of .NET. Here it is stated that an Informix provider is available for EF.
Have you thought about using Fluent NHibernate? There's a wealth of articles on the web for it, and plenty on SO!! Here's one such article : converting to Fluent NHibernate sessionmanager.
EDIT :
Been thinking about your situation and I'll tell you how I usually think. Firstly, I'll think about exactly what it is I want my Gateway layer to do (this is the layer I use to talk to the persistance medium). Now, most will say, I want it to talk to the database or I want to insert and update stuff. But recently, I have found this isn't enough! Halfway through coding a gateway layer with these questions in mind, I suddenly realised that I wanted to do something ever so slightly different, and boom, I couldn't do it using NHibernate very easily. So, I made a few concessions and went with Linq-ToSql as it supported what was a higher priority requirement over some of the niceties of NHibernate.
Now, the reason for my tale is this : NHibernate provides some great little features like Result Transformation. I can have a view on my Db with masses of joined tables, giving an aliase for each field and with a lovely result transformer, bang, it's instantly transformed into my DTO. Now, don't get me wrong, Linq-To-Sql has a similar thing with the auto-generated classes. But I don't want these visible outside of the gateway layer (another conversation). Equally, Linq-To-Sql handles transactions with ease - something I thought NHibernate didn't do so well!
So, it all boils down to : what are my EXACT requirements within my gateway/repository layer and what technologies are compatible with my persistance medium?! And now, I can think about what technology I want to use.
I realise I may not have answered your question per se, but I hope it has given you something to think about!
Happy coding,
Cheers,
Chris.
http://www.ibm.com/developerworks/data/library/techarticle/dm-0903linqentity/
The link above will provide you with links to download the informix provider, as well as take you through a step by step process of using the informix provider in conjunction with Entity Framework.
More about Entity Framework
http://msdn.microsoft.com/en-us/library/aa697427(v=vs.80).aspx
Simply put, once you have this set up you will be able to create classes that map to your informix data structures and perform queries using linq. EF is quite a powerful and useful tool, I recommend it.
My vote is with Fluent NHibernate - you get the configurability and cross-platform usage of Hibernate but you get to obviate the necessity of using massive XML configuration files. Entity Framework is good, but I don't like tools which rely too much on IDE/Designer support.
Happy coding,
Mel
I'd recommend Fluent NHibernate. Personally I see it used in more companies than any other ORM framework.
I've used Entity Framework, both design-first, which has serious lock-in drawbacks, and code-first, which is okay.
I posted an answer on Code Review when someone was asking an almost identical question.
i think its better to read this book first :
http://www.wrox.com/WileyCDA/WroxTitle/Professional-ASP-NET-Design-Patterns.productCd-0470292784.html
Related
We currently have a solution that was completely written by hand in ASP.NET and MVC.
There are a lot of ugly hacks and workarounds in the DAL currently and rather than expand on these hacks, I've managed to convince the suits that we need to migrate to an ORM of some sort.
With Entity Framework experience in the team, we've decided to go with the Entity Framework, however, I have a migration question for anyone who may have had an experience with this.
Would there be any performance issues if we were to migrate Entity-by-Entity until everything was migrated to EF? What possible roadblocks (other than the obvious of having to rewrite most of the BL) could we face? Should it literally be done Entity-by-Entity (in terms of, creating the models) or would there be issues creating the entity model and just changing the BL bit-by-bit.
I can't seem to find any documentation on the subject.. MSDN seems to just say "Yay Entity Framework is good, so migrating to it is good.".
Any advice would be appreciated.
PS: I did read this: Migrating from 'native' OODBMS to ORM (Entity Framework / SQL Server)
However as we've decided to go with EF instead of NHibernate, it didn't prove very useful.
It's good question and i have a answer from my prospective. It's about 'Yay Entity Framework is good, so migrating to it is good'
Now our team is working over big (very big) HR SaaS solution. From the beginning we decided to use:
EF 4.1
MySQL (that was requirement from client)
.NET MVC 3
Then time passed (near 3 weeks) we noticed next about EF: using Model first is not applicable and useful in our system in case of hard to support system in future when we need, for example, change a little bit db structure or make new relations between tables.
In this case we moved to EF Code First (with one generic repository for all db requests). That was the risk cause it's so new technology and there was no best practices or use cases on big solutions. As result we recived a lot of other headache:
ORM made a lot of db requests (cause of a lot of relations between tables). Fixed by .Include()
Dynamic Proxy for POCO objects - made a lot of troubles, cause in code first entities from db came not like requested entity type - like dynamic proxy type. So when we tried to serialize them and put to Memcached on deserialization we get the error that this entity no more available in current context. Fixed like this: http://msdn.microsoft.com/en-us/library/dd456853.aspx and this: http://blogs.dotnetkicks.com/dpeterson/2011/08/11/theres-a-proxy-in-my-boots-entity-framework-poco/
Stupid bag with Membership that sent a lot of unbelievable requests. Fixed by reviewing our work with Membership
Also we tried NHibernate to just compare performance. NHiberanate has the same :)
General info that you should know about EF:
If you want to attache 3rd part caching be ready for workaround. NHibernate have a native integration of this
There is no big different between EF and Nh performance, but Nh have a lot of hand work with mapping
Hope i answer to your questing and info is relevant for you.
ps> sorry for my English :)
Creating My Windows Form Application and using ADO.Net as Data Access layer and
SQL server as my Back End with lots of SP's.
Do i still stick to ADO.NET or go to studying FnH or Linq to SQL? Which shall i choose? Or i still stick in ADO.NET?
Can you give me Recommended WebSites on EF or FluentNhibernate for kick of tutorials..
Thanks in Regards
It's really just up to you to pick one - they're all valid technologies.
If you're already familiar with the low-level ADO.NET constructs, and you don't feel like putting the time into learning a different methodology, you can stick with plain old ADO.NET - this is not going away anytime soon.
If you want to start off with a very simple ORM, I would suggest LINQ to SQL. However, Microsoft has basically left LINQ to SQL in the dust in favor of Entity Framework, so if your project has long-term maintenance concerns, LINQ to SQL may or may not be the best choice. It is a really nice, lightweight, easy-to-use framework though...
If you want to learn the latest MS data access technology, you could try Entity Framework. The initial setup is not too bad, but Entity Framework is a beast, so there might be a bit of a learning curve at some point, if you run into something that works differently than you expect, or you want to learn more. EF is fairly full-featured at this point, but it still lacks some of the functions offered by more mature data access technologies like NHibernate.
Finally, if you want to try something different than the Microsoft offerings, NHibernate is a great framework. You're not going to find the entity designers, property pages, wizards, hand-holding, and stuff like that, but that's almost the point of NHibnerate. In Fluent NHibernate, the primary focus can be on your domain code, and less on the database, which makes it very conducive to unit testing. Entity Framework has gotten better with persistence ignorance, but it still feels a bit heavy-weight compared to NHibernate.
In addition to these, there are several other solid data access technologies that you could look into, but I hope this gives you some info to start with.
I would like your opinions regarding "DataSet Designer" and DAL (Data Access Layer) best practices.
I use Visual Studio 2010 Framework .NEt 4.0.
For my understanding "DataSet Designer" allow me to create automatically strictly Typed-DataSet with DataTable and Adapter, this consist in DAL directly in Visual Studio 2010.
I would like to know:
- If in real scenario "DataSet Designer" is working well, or is better write Custom Business Object.
- If exist other new solution introduced in .net 4.0
Thanks for your support! :-)
I have to work with typed datasets and it is a nightmare. If you have an option never use them. Everything is better.
With the advent of the .Net 4.0 framework and the introduction of LINQ to SQL, I've been adopting a customized DAL of strictly written business objects. We experimented with Entity Framework briefly, but ultimately concluded that it is very similar to DataSets in that the auto-generated code, while handy, is just too bloated with extra junk that we ultimately didn't use.
We've found that writing LINQ into our DAL and extracting data pulls into our custom classes, we are able to streamline our data access and control the usage of the data functionally. It has been a very handy process, but it has taken a little bit for the junior developers to grip onto it.
I would suggest a ORM like Entity Framework or Nhibernate.
Data Sets smells too much to database way of thinking and I personally had a lot of problems working with them. They just get broken quite often and throw weird errors that are hard to troubleshoot.
Some other related questions you may find interesting
What are the advantages of using an ORM?
ASP.NET DataSet vs Business Objects / ORM
Use ADO.NET Entity Framework, which is where the future of Microsoft's ORM is going. Or, consider an open-source one like NHibernate...
HTH.
At my company we've been using Typed DataSets for a little while now, and have had a generally positive experience. I understand that many people don't like DataSets, and there are certainly newer data access tools out there, but since you asked about a real-world scenario, here are some of my requirements and findings:
Need to be able to read SQL Server, MS Access, and FoxPro data sources
SQL Server access is only through SPROC calls (not my choice)
Relatively easy to learn, especially to developers new to ASP.NET
I've personally explored low level ado.net access, typed datasets, linq-to-sql, and simply writing custom data access classes. I have not looked at the Entity Framework yet, as the version included in VS2008 seemed to have some mixed reviews, and I did not have access to VS2010 until just recently(I do plan to review EF sometime this year yet).
We chose to use Typed DataSets because they seemed to offer faster development against SPROCS and we found a very comprehensive tutorial by Scott Mitchell on the asp.net site: http://www.asp.net/data-access/tutorials.
As to our experience thus far, it has mostly been good. The DataSet designer generates a huge amount of code even for small number of Tables (<20). Making changes in the SPROCS has caused a few headaches, but I'd like to be shown a tool that would make this easier.
One thing you might try to make your decision easier: Come up with a small domain problem like a customer edit page or order entry page, and implement it multiple times using a variety of technologies. It takes some time to do this, but it is a good way to learn and you can compare the technologies for yourself. We did this and it seemed to help a lot.
I will personally prefer custom business objects with their flexibility but its more work. Also look at with Entity Framework and Linq To Sql. Entity Fx has got a lot more flexibility in .NET 4.0. This article should get you started on Entity Fx.
If anything I think you should look into Entity Framework. There are lots of great tutorials out there to get you started.
I personally agree with Joel Etherton, conditionally.
If you have a small enough project that even with EF's bloat you're still not looking at too much shenanigan-code, I would say the expediency it offers is worthwhile. However in larger codebases, it can become a lot to get your hands around so much bloat.
The other benefit to EF vs older style business objects which goes unmentioned though, is with EF implementation you will probably get easier upgrades to newer .NET versions taking advantage of benefits in the next .NET without having to rewrite a bunch of code by hand. (This can also be a double-edged sword as upgrading to new .NET with EF may affect the behaviour of your dal as opposed to a hand-written dal is less likely to be so affected.)
That said, I agree with Joel Etherton, write the simplest smallest dal you can implementing LINQ, the dal is always too important to make overly-complex whenever it can be avoided.
If you do not want to waste you time do not learn DataSets. Study general concepts of object-relational mapping, their pros and cons. Look at projects like Hibernate for Java or Doctrine for PHP. Approaches behind DataTables and DataSets which provide just wrapping of database objects is over. Your framework should guide you to design you domain model, not the database schema.
NHibernate. Especially if you are using Oracle.
I am about to start a new project and am deciding what data access technology I will be using... I really like LINQ to SQL for a variety of reasons but should I start the new project using the Entity Framework instead??
I have this perception that the Entity Framework is more bloated and needlessly complicated, thus accounting for part of the reason I was thinking about going with LINQ to SQL... but as I said this may only be perception on my side as I haven't used the Entity Framework all that much.
So which would people recommend I use for starting a new project today (note this app will be around for years to come)?
Cheers
Anthony
EDIT:
We are SQL Server shop so we don't need database vendor independent.
Also is the generally agreed best way to abstract data access atm by using the Repository pattern which works with my domain objects?
LINQ to SQL is about rapid development and simplicity. If your data model is complex, or might become so, you will be better off using a more robust framework.
That said, more important than your data access tool is how well you abstract it from the rest of your code. Done right, you should be able to start with LINQ to SQL and switch when you outgrow it (or when EF 2 4 comes out).
Note that EF 1 is far from complete. It lacks all kinds of features you do find in LINQ to SQL, one of the more important ones being actual foreign key properties (can you imagine these don't exist in EF 1?)
Also, EF 4 will pretty much have all features of LINQ TO SQL, and both will generate relatively comparable (code wise) external API, so unless you're coding to very LINQ to SQL specific API's, it should be relatively easy to migrate to EF4 later on, 'simply' by replacing the LINQ to SQL .dbml with EF4's equivalent.
Linq to SQL works best in an active record / one table per class paradigm. If you need to span your class across several tables, or support complex inheritence then it may not be the best choice. Also, Linq to SQL doesn't natively support many-to-many relationships (there are workarounds).
If neither of those sound like they'd affect you, then Linq 2 SQL may be a good choice. It's a great lightweight data access strategy.
Linq to SQL can be used to implement the repository pattern very well given the above constraints. Google will turn up several viable Linq repository examples.
Have you taken a look at Subsonic - now in version 3 it is basically a linq to sql DAL that makes it possible to have full linq to sql of your entire database in under 5 mins. And it runs off T4 templates, so if you want to add to the templates it is REALLY EASY
http://www.subsonicproject.com/
I wrote up a pretty lengthy blog post on choosing a .NET ORM:
.NET and ORM - Decisions, decisions
Basically, NHibernate is your best bet. If you insist on something with simplicity like LinqToSql, consider SubSonic. I would not recommend either of the Microsoft options: LinqToSql or EntityFramework.
Deciding whether to use the repository pattern or not is situational depending on your requirements.
Check out: http://www.icemanind.com/Layergen.aspx
I want to make a perfect custom DAL (data abstraction layer) class to use with all my projects.
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.
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
Do all that and you will be fine.
Best approach is:
Don't do it yourself unless its for an academic research project or you intend to build a business shipping ORMs.
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.
ORMs are incredibly hard to get right and a huge undertaking.
Slightly related and on the money: http://wekeroad.com/2009/06/11/youre-not-your-data-access/
I can recommend you to read this article first. And take a look at EnterPrise Library's Data Access Application Block.
If you are a starter I would recommend use of SubSonic (more so if you are on web development).
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.
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.
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.....
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).
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!
Marc
Please read Data Access Layer Design Considerations
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.
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).
Martin Fowler describes several good approaches for writing data access layers in Patterns of Enterprise Application Architecture (here's a catalog).
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.
Linq to SQL is the best solution or you can try da easiest solution http://fluentado.codeplex.com/