I have read some articles about automatic code generation of ADO.Net data access layers in .Net applications. There are some tools available like CodeSmith or LLBLGen Pro. Does anyone has experience with these tools? Is it better to use these tools rather than using LINQ? Thanks.
Better is subjective - however, I understand what you're really trying to ask. Essentially, my answer to the question of which tool is right (best) for the job is: it depends on the job. Linq -> SQL is older tech of which M$ has no plans of updating or improving. I would stay away from it... if you want similar functionality Entity Framework or another ORM is best.
NoSQL is huge right now and offers a big boost in productivity due to no database development or mapping or ORM layer to muck with. Just create your entities and store them! My recommendations on those are:
RavenDB
CouchBase
MongoDB
Riak
Redis
Cassandra
There are also graph databases useful for 'networks' of 'things' that are related in some fashion or another.... the two that I've used are below:
Neo4j (popular, java based, has .net client)
Sones (.net based - newer kid on the block)
As for SQL databases - well, some companies don't want to endure a paradigm shift or have requirements that stipulate only x database will be used in the company, etc... In those cases you have to work with whatever you have to work with. ORMs can aid in this arena... Some popular ORMs are listed below:
Entity Framework (M$)
NHibernate (very popular)
Subsonic (older but still used)
Dapper
Massive
PetaPOCO
And as for regular ado.net and to address your main question - there are not a lot of frameworks that generate the data layer for plain ado.net, etc... but I did find these and it turns out to be very useful in my projects:
http://www.elencysolutions.co.uk/ (not open source)
http://spgen.codeplex.com/ (open source & customizable)
http://www.nettiers.com/ (open source but sorta old-erish)
Related
I am building a web api for my application and right now i am looking for ways to design my data access layer.
At the end, the application should be able to support a very large number of client and a very large number of queries.
I have heard about entity framework but i have two concerns with it:
I have been told by many that entity framework is not the best when it comes to performance, and performance is something that i can't afford to neglect.
I am only starting to build the application and i'm still looking for developers to join me, if i start with entity framework now, i might want/need to change an orm/library (because of the reason above or any other reason) or even a database technology in the future.
Repositories are a great way to abstract the data access layer and make it invisible to the business layer, so if one day i want to change the DAL/Database technology, i won't have to touch the business, only change the repositories.
Still, i have read a lot about how combining entity framework with the repository pattern is a bad practice.
I am really confused... and i have few questions.
Should i use entity framework? Performances is an important thing to me.
Should i combine it with repository pattern? If not, what do i do when i want to change the database technology/orm?
I have practice with using the repository pattern with native sql client (running native sql queries) but i don't have any practice with using orm's, at least not in .net
Is it really a bad thing for big application to use native sql queries and wrap them with repositories?
It is really important for me to begin writing my application in best way possible (applying all the best practices) so i won't have much struggle in the future.
Thanks,
Arik
Ad.1) Yes, Entity Framework is dead slow - BUT - when used out of the box, if the developers has deep knowledge of Entity Framework, what it does behind the scenes, how to optimize the queries - it can be as fast as your more low-lewel own implementation of data access.
Ad.2) If you want to change the ORM or the Database technology - that is not a matter whetever you use EF or not, it's a matter of the architecture you will design for the software.
Ad.1) see former Add.1, if performance is really important, I personally would go with low-level SqlDataReader, altough as I sad, it's possible to use EF in a performant way.
Ad.2) I don't see nothing bad in combining the repository pattern with EF, in small applications it may be an overhead, because the EF is basically an implementation of an repository pattern, so you would get a "double repository pattern", but it allows you to abstract away the coupling with EF
Ad.3) I don't think it's a bad way - but it depends obviously on the application.
I think that using a repository pattern is a good idea and a sort of wayout if you have some performance issues.
About Dapper the question is why Dapper is more performant than EF and NHibernate. No Lazy Load, no DML, easy mapper and so on. If you want DML (I do) and sometimes Lazy Load you could have a mixed approach. Repository Pattern + EF + Dapper.
My approach actually is Repository Pattern + EF + very few query (massive update and delete and few select - EF writes huge SQL statements also for simple queries - ). To map the select you can include Dapper (I don't), do it by hand (manually mapping or use the features inside EF - but there are some limitations - or write something generic). Usually I map it manually but I wrote also a mapper based on EF Mapping
Entity framework Code First - configure mapping for SqlQuery
I used it for few times and actually I don't use it anymore.
I've got a client who wants an ASP.NET MVC application. I'll develop it with VS.NET 2010 Express, demo it to him on my Linux server during its development (Mono supports ASP.NET MVC), and he'll eventually host it on a commercial provider running IIS.
Getting this done quickly is the name of the game. The only piece I'm missing here is the database layer. Ideally I'd use SQL CE and EF4. But SQL CE only works on Windows, and Mono doesn't support the Entity Framework anyway.
The only free Linq to SQL-like option I see is DbLinq. A quick test with that on a MySQL database had it erroring out on a table that had two foreign keys to a single primary key. A search on Google shows that this bug was identified, and a patch was created, two years ago or so. That the patch still hasn't been applied to the main source by now, and that this bug seems to affect so a common scenario, does not fill me with confidence on the production-readiness of DbLinq.
Even if it did work, it'd have to be with MySQL, as that's the only database I can expect to be available on both Linux and an eventual Windows server. (SQLite, Berkeley DB, etc., would all require some native drivers be installed on the server, which I can't count on.)
I don't know NHibernate. But from what I read, it requires manually creating XML mapping files... so I don't have to write SQL statements, but I do have to create mapping files? (Plus I'd need to learn how to use it.) Like I said above: Getting this done quickly is a goal here.
If I must, I will just pony up the $5 a month or so for a cheap ASP.NET hosting provider and use that to demo progress to the client, using SQL CE and EF4. But before I do that I'd just like to see if there are any other viable options. (It's kind of mostly an intellectual exercise by this point.)
So... any tips?
Does it really have to be a fully bloated ORM?
I recommend to have a look at some of the so called "micro-orm`s", especially my favourite one: Peta-Poco (http://www.toptensoftware.com/petapoco/)
Peta-Poco runs perfectly under mono and has an incredible performance. Even better, because of the small codesize (~1k lines of c#) it is very easy to understand what`s going on under the hood and you can easily change/extend the code to your needs. For the start you just have to copy the single .cs file in your project and you are ready to go.
Peta-Poco has a very well poco-mapping heuristic so you will get your c# objects out of the db with zero configuration for the most cases.
You COULD try Linq-to-SQL. Partially supported under Mono from 2.6, it supports many dbs under mono Release Notes Mono 2.6 (they are working with those of DbLINQ to make it).
Ah... Forget to learn quickly how to use nhibernate. It's very good but it's quite an hell. And creating the XML is the least (and with NHibernate 3.2 they have added their version of Fluent interfaces, so XML aren't anymore necessary I think. You can "code" your XML.)
I'm working on a new project right now and am thinking of using an ORM beyond that of Linq to SQL. I've currently got Linq to SQL wired up into a repository, but I'm not loving the way my Repo has to match my DB structure. (Example: I have a join between Users and OpenID's, and I need a 2 classes ( one for each table) and a class for the View that joins them).
I've heard some good things about Telerik's OpenAccess ORM and I do have a license for it (though outdated - Latest Version: 2009.1 405 (Apr 5, 2009))
My questions are...
Has anyone used it?
How is the learning curve?
Is it a good tool for my above scenario?
Is the version I have ok without having to update my license?
Our company is a $2.5B solar manufacturing company. When we started designing v2 of the application framework backend that all our applications would be based on, we took a look at the Telerik ORM. I spent a couple weeks looking at it. Our conclusion was that it was too complex, and a little flaky, for our needs. We went with L2S and have not regretted it. L2S has provided all the capabilities we need and is simple and straight forward. IMO, it's too bad Microsoft is spending so many resources on Entity Framework, because they have a winner in L2S.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have around 4 years experience of ASP.NET & SQL Server (only web forms). I have a little knowledge of Ruby on Rails and have developed one very small 2-3 pages application in ASP.NET MVC in my job. Now I and one of my friend ( same experience like me) are willing to gain more experience of ASP.NET MVC. For that purpose we have thought of developing an open source application in ASP.NET MVC. It can be a a blog system or forum or anything else so that community can also take benefit of it. But we are not able to decide the back-end database for the application between MySQL and SQL Server. What will you suggest in terms of following -
Which will be more supported or required by community?
If we use MySQL, will it be a tough road ahead?
Is there any chance of supporting both by using ORM (I have no experience of working with any ORM)
Any other suggestion ?
Thanks in advance.
If you can't decide which to use as a backend, then one suggestion I have it define an interface for the data layer, use the IRepository pattern against this interface, and simply pick one and write an implementation of the data layer for that choice. In a (successful) open source project, it's unlikely that everyone who wants to use it will have the same ideas about what database will work for them. In that case, designing it so that it can use any database, given a suitable implementation of the interface is a wise move. Using something like nHibernate, which already supports many different databases may be the route you want to go if you don't mind having dependencies on other libraries.
Which will be more supported or required by community?
For most business users, and most dedicated ASP hosting providers, it will be Microsoft SQL Server IMHO. With a surprising spread across version numbers. I see quite many SQL Server 2008, a lot of 2005, and quite surprisingly many 2000's too.
For small "we're cheap, is it gratis?" businesses and individuals, I do see some MySQL on Windows too. I guess in my little circle of companies that I've worked with, it is 2/3 MSSQL and 1/3 MySQL of the two databases you mention.
If we use MySQL, will it be a tough road ahead?
In terms of more difficult development? Yes and no; LINQ to SQL is more or less only available for MSSQL, and many find it to be a simple and natural technology to work with. So "yes" if your plan was to use LINQ to SQL as your ORM of choice. Other good ORM's like nHibernate work equally well with both databases, as elder_george says.
Is there any chance of supporting both by using ORM (I have no experience of working with any ORM)
Sure, f.x. with nHibernate, and a bit of extra XML for nHibernate configuration, and some more extensive install docs, SQL scripts et cetera for the users.
Any other suggestion ?
Since this is your first application, play around with the design first using mocksups & prototyping, UML or something else of your choice. See if you can get some experienced MVC developers to critique your design, but don't take their critique as gospel, there is more than one way of doing things right.
Definitely consider tvanfosson's suggestion to use an IRepository to provide flexibility on the storage layer.
Consider using unit testing and dependency injection from the start too; both are IMHO very important and helpful in the longer run. On the downside, that would be a lot of new technology if you don't have prior experience with these.
MS SQL is easier to use with .NET. .NET includes LINQ to SQL ORM out-of-box, so nothing has to be installed.
MS SQL has a free Express edition but it's up to you to decide whether its capabilities (4Gb for DB, 1 CPU only and so on) will be enough for your application (IMHO they will be =))
There'are ORMs that allows to switch between DBMS's: NHibernate, SubSonic, DbLinq. NHibernate is the strongest beast out there, and it has an active record implementation built if you are looking for familiar concepts from RoR.
tvanfosson and elder_george had given good comments.
ASP.NET MVC aside, it's more of MySQL vs MSSQL. I've developed web projects using both and find them relatively on-par from a development point of view. ORM I've used is NHibernate.
From deployment/production perspective, you will be bounded by MSSQL Express edition's limitation, assuming you are not going to pay for it. You might want to spend some thoughts in this aspect.
Use ORM -> NHibernate
https://www.hibernate.org/361.html
I was in a similar situation a couple of months ago. Now my newest project on ASP.Net MVC is almost complete. Here's the set I chose
--ASP.Net MVC + MySQL. No ORM.--
I decided to go with MySQL instead of MS SQL because MySQL is free, and MS SQL is very expensive. If you're making an open source application, you gotta think about that seriously. This is going to be a major problem if you are targeting widespread adoption of your application.
At first I tried to use MySQL through an ORM -- Enterprise Framework (EF). It was the worst decision ever. Enterprise Framework totally killed the performance. It was the pits of the pits. I believe nHibernate is better, but I don't know how much better.
With my own SQL code things are fast enough.
The first iteration of my site will be in public beta this week and then there will be several iterations.
It went rather well so I car recommend the set I chose with ease.
We are getting ready to begin redevelopment of a large aging internal enterprise application. We have decided to use ASP.NET MVC, but under consideration is which Object Relational Mapping (ORM) to choose. There are of course a multitude of open source and paid ORM implementations available. However, NHibernate seems to hold the largest mindshare, while the Entity Framework is the new hotness from Microsoft.
While we are doing research and toying around with both we wanted to put it to the community as to which ORM (NHibernate, Entity Framework, or otherwise) they prefer and why.
Somewhat similar Stackoverflow Questions
What are you favorite .NET ORMs? (good list, but w/o justifications)
ASP.NET MVC + ORM (focuses primarily on Castle Project AR)
What object mapper solution would you recommend for .NET? [closed question]
Additional .NET ORM Reading
ORM in .NET 3.5
Why use the Entity Framework?
Why use the Entity Framework? Yeah, why exactly?
Best .NET ORM Tool
You should have a look at Sharp Architecture an ASP.NET MVC application framework which uses NHibernate.
I've used a few O/RMs in the past couple of years and there's no way would chose anything other than NHibernate.
It's the most mature.
It's got a huge set of features.
It's got a good community behind it.
It's got some fantastic ancillary projects such as Fluent NHibernate.
I don't know what more information people will be able to give you over and above in the questions that you have linked to.
Crazy talk answer: none.
This is not to say ORMs are not awesome pieces of technology when used right. But in 2011, they are quickly becoming the universal hammer where not all problems are nails. And there is so much going on in the modern ORMs that, especially for people not well versed in them, they can confuse things more than help things. Or, sometimes things are simple enough that straight SQL is a better alternative. No matter how good the ORM is, the abstraction will leak at some point.
The other side of things to look at is the whole NoSQL movement. The technology is still a bit new, but for new work it is a data access strategy one must consider as it takes so much cruft out of building your application.
Short answer: use both (i do really use both)...
With ORM there are multiple possibilities, all depends what you want.
As a real ORM mapper I strongly recomment NHibernate and Fluent NH mappings. You need a lot of research to put together a nice architecture, but then nothing stands in your way. With minimal compromises you get real flexibility.
EF6x (core is not prod.-ready IMHO) is called an ORM, but what it generates is more closer to a DAL. There are some thing's you can't do effectively with EF6. Still, this is my favorite tool for a read-model, while I do combine it with NHibernate (where NH I use for a DDD/write model).
Now to performance - its always pro and cons. If you deep deeper into ORM architecture (see my article: avoid ORM bad habits) then you will find intuitively the ways to make it faster. Here's my another article on how to make EF6x 5x faster (at least for read situations): EF6.x 5x faster