I need to choose an ORM for a project and I only have some experience with NHibernate. I have been reading Q&A from StackOverflow, and the most similar to my needs is What ORM for .net should I use?, but I would like to have an answer more adequate to the present products (the link is from 2009) and that also take into account some points of my project.
The easiest solution for me would be to use NHibernate because it is mature, feature rich and I have already used it, but I prefer to choose the best option for the project even if I have to "study" again.
The project is going to start as a core that communicates with SAP. The core has to support standalone and/or co-dependent modules, and each one of them may need to work with its own data from the database. The final step will be to implement the part of SAP that we use. The characteristics I need are the ones from the previous link and here are some more things to have in mind:
I would like to be able to split the data access layer so that a user with one or two modules won't need the whole thing.
A designer would be appreciated.
It will start with about 20-30 tables and, within a couple of years, that number will grow in several hundreds.
The amount of registers per table will vary from two or three to 150000+ (very few).
IT DOES NOT NEED TO BE A ONE PRODUCT SOLUTION. Combinations like NHibernate and Devart Entity Develop are also welcome.
The team for this project will also have students that will have to learn C Sharp and some of them probably don´t know exactly what an ORM is, so it would be great if it is simple or, at least, the basic stuff is not very complex (mixing tons of lambdas, reflection, extension methods, etc.).
The last one is not very important. I hope this is specific enough to avoid been closed (the question I link is still open).
EDIT:
-It is a desktop application.
-Documentation and comunity are also very very important.
The most popular ORM for .Net these days is Entity Framework. It comes from Microsoft, so well documented in MSDN style. And it fits your criteria.
I worked with NHibernate and found that documentation is patchy, inconsistent and sometimes missing. Most of the time I had to use docs for Hibernate which were not for NHibernate, just similar.
EF can do the same things and more than NHibernate, and the latest release have Migrations, which was missing (when I worked with NHibernate).
Consider it Dapper: dapper-dot-net.
Dapper is a pretty simple ORM, developed and used by StackOverflow.
There is a lack of documentation, but that is because of it simplicity. You can find some usage example in the project page or in some websites like this.
I know this is a pretty old question, but I though I would post an answer for anyone who lands here. Check out SQL Data. It is extremely simple to use, very powerful and fits all the OP's requirements.
Related
I am currently intresting on learning myself using Entity Framework since I like the basic idea with OR mapping.
However to learn this my intention was to take a certification in Entity Framework (DataAccess the certification is called in Microsoft world).
After have started to read the exam book and also doing the labs I have come to the conclusion that many things gets pretty hard tightned in the UI with the Entity Framework (at least in the book). I refuse to think that this is the way it's done in the real life projects.
So I have two questions (maybe they map together a bit):
How do I realy handling the ObjectContext in real life? Is it realy open all the time as in the labs? They passing it around to different windows and keeping it open. This feels for me at least pretty stupid at least in the way of re use of my code. Since in the end there will be X amount of database questions that is exactly the same in a bigger project.
Do anyone have a good link to a pattern that you have used for your Entity Framework solutions in a real project?
Thanks alot for your time!
MS Certification exams and real life development have nothing in common. Those two are completely different worlds. So don't bother yourselves with crappy approach you have to use to complete labs in book (well you can make your own lab and spend much more time on correct approach if you want). That examples don't use layered architecture and they don't deal with separation of concerns.
Simply it is not done this way in the real world but explaining how it is done requires exact description of what type of application you want to do and what operation you want to execute.
Some info about the certification itself:
I took both DataAccess certification for .NET 3.5 and .NET 4.0. My experience was horrific. Especially DataAccess .NET 4.0 is probably the worst MS exam I have ever taken. I believe I understand EF little bit and I prepared myself by skimming through several chapters with topics I don't use very often in Programming Entity Framework, Entity Framework 4 Recipes, Entity Framework 4 in Action and Pro Linq (for Linq-to-Sql) + I read the whole ESQL reference. The training kit for this exam was not available during my preparation. It didn't help me at all. The exam questions about EF had very poor quality and I was lost most of the time because I felt that I needed more information to correctly select answer (with requirements provided more then one answer or none answer looked correct) or I needed to select more then one answer to fulfil all requirements in the question but I was allowed selecting only one.
Be aware that exam is not only about EF. In .NET 3.5 the exam contains almost none questions about EF. Half of questions in .NET 3.5 exam is about DataSets (OMG). In .NET 4.0 the exam contains half questions about EF, a lot of questions about plain old ADO.NET including few questions about data sets and few questions about remaining topics like Linq-to-sql, MS Sync Framework and data services.
I don't like to write it but .NET 4.0 exam convinced me that brain dumps can sometimes be handy because there is no appeal if you think that test was not correct or questions were not unambiguous.
You are correct that the labs do suggest working like that is just fine. I suggest you take a look at Entity Framework 4 in action.
Most of the time you'll put your entity framework context behind an interface to reduce coupling and improve testability. With EF4 (and even better in 4.1) we also now have POCO support which means your entities don't have to inherit from any special Entity Framework class.
A little briefing first; I've been a Delphi person for years, and been away from C# for two years. The last thing I've done in C# was a mid scale DB app with my own custom DAL. Ie, I had coded my own functions to retrieve data as list, functions to append data and so on. Now I am offered a small to mid scale project using C# WinForms and SQL Server, and there's a deadline which is about 2 or 3 weeks. Note that I forgot LINQ syntax and lots of things.
Now, which ORM would be easiest and fastest to learn? I can cope with not using business abstraction layer if need be, to gain time that is. I need something that'll ease manual labour. Thanks in advance.
For quick-to-implement etc, I'd look at LINQ-to-SQL; the jury is still out on who considers it to be full ORM, but tbh I don't care; it lets me map my data quickly, simply, conveniently and safely, with decent IDE/language support. The LINQ you generally need is pretty minimal... from, where, select, etc. And setting it up is just a case of telling the designer about the tables/columns vs clases/properties.
If I were you I would go for Entity framework. It's pretty simple,easy to implement, efficient and successful ORM tool. You can use LINQ as well in the entity framework while retrieving the data.
As a recent ex-Delphi developer I've been amazed with using MyGeneration to generate basic DAL/BLL classes from an existing database, via custom templates. Takes a lot of the drudgery out of the task.
I've also seen some high praise for Business Logic Toolkit for .NET. Its clean and simple architecture and small learning curve makes it very attractive. Not really ORM, but will get you up and running quickly.
If you search for the terms C#/ORM here, you will find lots of lively and interesting debates!
Choosing Database and ORM for a .NET project
Some suggestions on which .NET ORM to look at learning
https://stackoverflow.com/questions/132676/which-orm-for-net-would-you-recommend
https://stackoverflow.com/questions/146087/best-performing-orm-for-net
If you don't mind a commercial product, Lightspeed is almost too good to be true. I've used it for about 6 months now and it has helped me in every way possible, from designing the model using a graphical tool, to migrations when upgrading, updating the database with a single click, good unit testing, easy custom extending, validation, etc. At least try out the free version!
I have a project on .NET and MySQL. I've learned Devart LinqConnect in three weeks to complete it. All of LINQ functionality, wide support of MySQL, high quality support - like this product.
At work I need to create a new web application, that will connect to an MySql Database.
(So far I only have expercience with Linq-To-Sql classes and MSSQL servers.)
My superior tells me to use the entity framework (he probably refers to Linq-To-Entity) and provide everything as a service based architecture. Unfortunately nobody at work has experience with that framework nor with a real nice server oriented architecture. This speficic project I'm leading will be long-term, meaning multiple years, so it would be best to design it the way, that multiple target plattforms like asp.net, c# wpf, ... could use it)
For now, the main target plattform is ASP.net
So I do have the following questions:
1) Where can I read best what's really behind service oriented architecture (but for now beginner tutorials work fine as well) and how to use it in best practise?
2) So far I can't see a real difference between Linq-To-Sql classes and the information I've googled so far on the 'entity framework'. So, whats the difference? Where do I find nice tutorials for it?
3) Is there any difference in the entity framework regarding the database server (MSSQL or MySQL)? If not, does that mean that code snipperts I will stumble across will word database independent?
4) I do use Visual Studio 2010. Do I have to regard something specific?
Also on the MSDN site are a great series of videos by Julie Lerman on EF 4.0
Videos
The idea is that this is meant to be as painless as possible.
Generate your entity model from source database(s)
Publish using .Net Data Service
Write client components to subscribe to the Data Service
I could explain how ll this works but i feel its best to let the experts say it all ...
http://msdn.microsoft.com/en-us/library/aa697427%28VS.80%29.aspx
Sounds like a great project, good luck with it :)
Hope this helps.
Have you checked out the microsoft white papers? For example here.
If I were leading a team on a project that size though I'd be looking to pick up some good books, and I'd be asking my employer to pay for them. Get on Amazon and see what has good reviews. There's only so much you can pick up from the internet imho.
I'm investigating technologies with which to develop a medium-scale (up to 100 or 200 simultaneous users) database-driven web application, and someone suggested Morfik. However, outside of the Morfik company I can find practically zero community support - no active blogs, no tutorials, no videos, no books - and this is of some concern (especially when compared to C# / ASP.NET / nHibernate etc support). Deciding between Morfik (untried and not used widely AFAIK) and the other technologies I mentioned (tried, tested, used widely) is becoming a critical issue for my company.
Has anyone had success using Morfik in these kind of circumstances? What kind of performance did you achieve?
Being a Morfik user for the last 2-3 months, trying to do a quite large project. I totally understand your concern.
The community is small, Morfik developers though try to help you and answer almost all your questions. It was one of my concerns before purchasing it, but it's not a big deal actually.
However, it lacks documentation and tutorials. Yes, there is a chm help file, but outdated and lacks in many ways. Not enough examples, you should figure a lot of stuff on your own. But they say, it's Morfik team's one of the first priorities in the upcoming release to enhance the documentation.
We chose not to use Firebird as the db (Morfik supports it natively) and going with Postgresql over ODBC. There are issues to overcome there too. We had to dive in and modify (override) our own security wrapper for postgre etc. But overall, Morfik integrates with it quite fine. You should be prepared to small annoyances though.
We chose to go with Pascal version, as it is the major language the developers use. But, oh I hate Pascal so much :) It had been 10+ years last time I used Pascal and it can be really annoying with the quirky code editor of Morfik.. I miss VisualStudio, or even Notepad++ as editor!
Since we started our app, I see new components and examples released quite frequently. Morfik team invested on a separate team that develop addons for Morfik, which is a good thing.
So, in terms of support (not community but staff) you should not worry. It's still far from being a mature product but it does the job. Our relationship with Morfik is a love and hate one. I am quite sure our big project will be successfully completed with Morfik, and I can do small enterprise solutions with Morfik very (I mean very) fast. But I would also really think again to use Morfik if we do a big project like we are doing now.
I hope I make sense :)
You might try looking at www.morfikwatch.com which a blog dedicated to Morfik. There you will find links to a couple of Morfik user communities. You can then ask around.
We use Morfik for a variety of purposes, all intranet based. We are looking at the migration of all in-house corporate applications being refactored into morfik applications.
Morfik is a new product, and as such, the community is still growing. Although Morfik 1 has been around for awhile, Morfik 2 is the first version that makes it easy to develop plugins and other third party tools. Now there are small websites starting to appear that create plugins and support Morfik. (http://www.pannonrex.com/ for example).
Morfik is in it's infancy yet offers a solution to be found nowhere else. I would recommend it highly. Just give it time and the developer community will appear just as it did for Delphi and the rest.
best regards
Dalton Calford
Distributel Communications
I'm sorry, when I saw 100-200 simultaneous connections, I immediately thought you meant intranet. We average 300-450 concurrent users on our apps, so we do not consider it a internet based app until you look at a possible 5,000+ users.
The design criteria for such a system is very different than a system with under 1000 users.
When you approach such a system, you are looking at a cloud configuration. As our company is a telecommunications company, and we are required by law to meet 5-9's service for our customers, we use firebird in all our back end processes. Although we have used DB2, Oracle and other products in the past, Firebird has either been more reliable or outperformed the others.
With the about to be released Firebird 2.5 (now in rc 2 if you wish to play with it), you can use firebird as it's own middle tier, with one database connecting to multiple other databases to perform both DML and DDL actions. You can have one Firebird database that has no tables whatsoever, just stored procedures, views etc. That database can then surface the data from multiple sources without the client application knowing. As the connection can be dynamically built within the stored procedures, you can have the backend databases change as needed without changing any front end code. This allows you to load balance, have multiple web servers share a single cluster of databases etc.
So, I since Morfik supports Firebird intrinsically, I would say that yes, Morfik can scale well to a larger environment without trouble. As for Firebird support, it has one of the most active user communities on the web.
From the point of view of Morfik, morfik is a great way to generate a web based UI while leveraging your existing developer base without having to learn a series of new languages. But, it currently lets the developer use the tools for n-tier development without getting in the way. I like that. I do not want a tool that tries to be everything and in turn, does nothing well.
best regards
Dalton Calford
Distributel Communications
Something that I am very concerned about is 3rd party components. GWT has a fairly large collection of components. We make extensive use of data grids that need to be data aware and very rich, meaning it needs to be able to do grouping and sub groupings and master detail relationships.
You must also be able to create new groupings on the fly.
We also make use of pivot grids a lot, so we need them as well, and a quick google search doesn't show any components that can compare to what is already available in GWT.
It is a pity though, since the Morfik development environment seems very integrated. The GWT environment is a bit funny to me, since I am used to the Visual Studio and Delphi environments, so the way Eclipse work is a bit foreign to me, especially when adding new components to the different designers and editors in eclipse.
Morfik is quite limited web development environment for a very basic web development. Even if it gives some benefits in the very beginning in long term it will tie you up.
I worked with Morfik for two years, you can undoubtedly make applications fairly quickly for the management that has design and maintenance is literally 3 clicks, but when you want to add a little more robust functionality can become a pain of head, without counting the inconvenience that is to adjust the reports, has little documentation and the components are the majority of paid.
If you want an app in a short time and not very robust Morfik is indicated, if you want something more I do not recommend it.
I am working on a .NET web application that uses an SQL Server database with approximatly 20 to 30 tables.
Most tables will be included in the .NET solution as class.
I have written my own data access layer to read the objects from, and write them to the database.
The whole thing is consist of just a few classes and very few lines of code en uses generics and reflection to find out what SQL and parameters to use.
Now, such thing could be done by using NHibernate (or similair framework) and some co-workers claim that is foolish of me not to use it.
My main argument for not using it is that i want maximum control over my application, know exactly what everything does and how everything works, even if that costs me more development time.
I also dont like the fact i have to map my database in XML files (my own solution lets me map it in the entity class files).
So, what i would like to hear from you is, is it really stupid to not use NHibernate in this situation?
Am i really being ignorant or is it not such a strange idea to use my own solution?
I think these days there really isn't any reason to roll your own persistence framework since there are so many good choices out there. You don't have to use NHibernate (though it is a good choice) but I would seriously consider using something that is well tested and established in the industry as it will tend to perform better and have less bugs that something you write yourself.
It probably is foolish to write your own classes instead of using NHibernate, but it's less foolish to continue using your own classes, given that you've already written them. Maybe.
I won't call you foolish because I've done exactly the same thing in the past. Then I started using NHibernate and wondered why the hell I rolled my own. It's good, give it a go.
You have several possibilities that are probably better than you reinventing the wheel. Let me name two most likely choices:
Use Entity Framework for your DAL+DAO. This will make your classes (that you've already written) obsolete, since EF will create their own and you'll get up to date with latest language capabilities and technologies.
Use Fluent NHibernate so you don't have to work with XML mappings. This way you'll keep your business layer object classes you've written and avoid tedious NHibernation XML files. It's all C#.
Your way of thinking is good. You want control. That's fine. But using your own DAL is a bit foolish these days, because you are basically reinventing the wheel, plus you'll have not tested/buggy code that will take considerable time to develop+test+debug.
If I were you, I'd go with the #2 option, since I've done option #1 and I know I had to customize lots of things to make EF work as it should. EF will be ready with V2.
People tend to use frameworks that are already written because, well, they're already written (and tested).
But there IS merit to rolling your own. Only you and your colleagues can make assumptions about your domain. A generic framework like NHibernate cannot make many assumptions, because that wouldn't make it very universal.
When you roll your own, you can bake these assumptions into your framework, to make a more streamlined, natural API. That said, if you were starting over I would have suggested taking an existing framework and wrapping it to better suit your needs. But since you already have something and it works for you, I'm not sure that I would suggest swapping it out for something else.
It depends on what they mean by "foolish."
If by "foolish" they mean you shouldn't have written your persistence layer in the first place, they're probably right, but that's crying over spilled milk.
If by "foolish" they mean you should rewrite all your existing code to use another framework (like NHibernate) when it's already working with yours, they're probably wrong (although there's something to be said for # of bugs in NHibernate vs likely # of bugs in yours).
If by "foolish" they mean the entire team knows NHibernate cold, and it's already used in the rest of your code, so by using your framework you're making it harder on the team, they're absolutely right, and you should probably refactor the code in NHibernate as soon as possible, before any more code gets locked in to your framework.
If by "foolish" they mean no one there really knows NHibernate, they just like it, then... nobody wins. They're being fussy, you implemented a framework you didn't have to... let's call it a tie.
All of that said, everyone should write a persistence framework or three. Those probably shouldn't end up in anything that ships, but it's a good exercise. The only mistake you made was tying code the team had to maintain into your good exercise.
There are many good persistence tools out there that are well tested and have proven performance (NHibernate, Linq to entities, LLBL Gen Pro). If your needs are very different from the normal persistence frameworks that exist then I would roll my own. I would want to take advantage of the testing and optimizations of an existing tool if at all possible, however.
That being said, I might also roll my own if I wanted to have the experience of building my own ORM tool and was willing to live with the downsides (not as well tested or optimized as tools that have been around for years, speed to market).
Making your own solution, especially when it seems to work fine and be as simple as you say, is neither ignorant nor strange. There are lots of situations where it's better to do that than to add a dependency on a separate project like nHibernate.
That said, there are of course also a lot of situations where the complete opposite is true. :)
It really depends on your project and team. If you are developing an enterprise application that will eventually be supported by someone else, sticking to industry standards might be a good idea even if it means a bit more work up front.
All of the answers here are great, but I am really surprised that nobody has mentioned Castle ActiveRecord, it sounds very similar to what your framework does and really simplifies the interface to NHibernate. It's one of the patterns that made Ruby on Rails so popular after all!
Ayende Rahien (one of the principal NH developers) gave a GREAT presentation on ActiveRecord at Oredev a few years ago which I highly recommend: http://www.viddler.com/explore/oredev/videos/89
I think that it is a matter of balance of control. You say that you want control and you don't want mappings. If this control comes at the cost that there is an increased development and maintenance cost and that it takes longer to produce working code, then it is a problem.
I personally don't see a problem in rolling a framework as long as it simplifies a repetitive task and makes development more productive and code more stable due to less room for interpretation. We have rolled our own framework, that includes a persistence/data access implementation. Our reasons for doing it, though, were specific. In this case, it was to work within a DDD environment that was much closer to what Evans describes than what most off the shelf products were providing.
I think the difference is, though, that we understood that there was an upfront cost and that it would eventually balance itself out through savings in development time in the future. Of course, if you are writing code that you manually have to manage connections, map data, etc., you are probably going down the wrong path. At the very least, you could be using something like Enterprise Library to help you manage the tedium of connectivity and command construction. But, I also think, that if you have no reuse - nothing that is a "framework" type of implementation that you can abstract and apply to other projects, then you are creating a maintenance nightmare and time sink that you will be the sole owner of.
We were also using our own Data Access Layer and entity classes. We also had a code generator who used to generate all this classes for us. But now we are using Entity Framework and we are more then happy.
Simple advise : Start learning nHibernate or whatever you prefer and start using it in your next project.
Entity Spaces - http://www.entityspaces.net/Portal/Default.aspx
is also a good tool.
I ended up using Fluent NHibernate for the job.
All my entity classes were generated with ActiveRecordGenerator (http://code.google.com/p/active-record-gen/)