I have a small application in C#, and so far I have implemented it using data persistence classes that are running SQL directly, I understand there are better alternatives as Hibernate.NET and possibly Spring.NET.
There are some other I forget? pros and cons?
thanks!
Here are a few of the more common ones:
LINQ to SQL
ADO.NET Entity Framework
NHibernate
Plain old ADO.NET
SubSonic
Spring.NET isn't really a dedicated data persistence framework. It's more of a IoC (Inversion of Control) framework, which gives you dependency injection, and a bunch of other stuff, including the ability to plug in a data persistence framework.
LINQ to SQL and SubSonic are probably the easiest to use and learn out of all of these. NHibernate and Entity Framework are more complex, but probably also more powerful and flexible than plain LINQ to SQL.
Related
Is there a way my DAL classes can be re used across different databases ?
I know some technologies (Linq and EF) support rapid development, I appreciate this feature but I also want to keep my DAL Code reuse able in different database.
A Simple thing that come to mind is use of Oledb with inline SQL queries, Is there a more elegant way ? please guide me. I am just considering 2 things.
support to 4 most commonly used databases (SQL Server, My SQL, Access, Oracle).
Rapid development support.
Thanks
You may consider using an ORM framework such as Entity Framework or NHibernate. This way your data access layer will be database agnostic.
If you stick to the interfaces (IDbConnection, IDbCommand, ...) and their factory methods (IDbConnection.CreateCommand) then the only code that needs to know what database you are using is the initial connection creation (which can be encapsulated).
Entity Framework does the work you want. The most commonly used databases support it, with the exception of Oracle. For Oracle, you have to use third-party components as the official Oracle support for Entity Framework is still in beta.
I am currently working on a software project which uses SQL Server database to store data. Since there are some plans to move away from SQL Server to Oracle, one of the requirements is to build pluggable database layer.
So my question is what is the best way to do it?
You have lots of choices. One option is to go with one of the various Object Relational Mapper (ORM) frameworks out there. NHibernate is a popular one, but Microsoft's Entity Framework (in v4) is a reasonable possibility as well, and it integrates better with Linq, if that's the sort of thing you're interested in.
A second option (not necessarily exclusive of the above) is to implement something like the Repository pattern, and run all database access through a repository layer. Some folks see the ORM frameworks as a replacement for the Repository pattern; other see a repository layer adding value on top of the ORM framework. The real value that a repository gives you is the ability to swap out ORM layers. Only you know whether that's a reasonable likelihood, and even if it is, it may be more work to implement the additional repository level than to just re-bind everything to the new ORM.
I suggest using Entity Framework, quite easier than NHibernate and being matured very fast. For oracle support in EF, you'll need the oracle provider.
Along with using Entity framework, I suggest using a pattern such as Repository Pattern. This way, you can use Dependency Injection to change the implementation of your choice. Your application becomes independent of database or the ORM itself. So you could also use NHibernate if you wish.
I would recommend using NHibernate for your data layer. With it, you can easily swap out the configuration to work with almost any database driver you want.
NHibernate has good support for both MsSQL and Oracle.
You can write all your queries in Hibernates query language (HQL) which will be dialect agnostic. Another option is to use the linq provider in NHibernate 3 to get strongly typed data access.
As some other have mentioned, i would also recommend using the repository pattern and inject a Unit of Work or a SessionFactory.
Edit: Oracle now has released a beta of their Entity Framework provider: http://thedatafarm.com/blog/data-access/oracle-entity-framework-beta-released-today/
1: http://nhforge.org/Default.aspx## Heading ##
If you want to go ORM way, you can use NHibernate as alexn suggested, or Telerik's OpenAccess ORM. There is also EF provider for oracle and other DBMSes, but they are not free.
If you want to build your whole DAL from scratch, than go with Repository pattern. Create an interface for repository and create each repository provider for each db. Here's a discussion about.
As I began writing web applications with ASP.NET I started with small projects that used a Linq-To-SQL mapper for database access to a MSSQL Server.
After gaining some experience, I switched into a classic three-tiered approach with a graphic Layer, business Layer, and a data Layer. The only function of the data layer was to provide insert/update/delete-methods without any logic and logic the form of selection methods.
Over the time I realized that it would be better not to provide the database classes up to the GUI (took some time, unfortunately). I switched to using business classes in the BL that are used for all operations performed by the BL and displayed by the GUI in the form of getting List from the business layer.
A great advantage is that I can provide additional properties that are not represented by the database itself. However, I did that mapping inside the business layer myself with methods that mapped the corresponding business layer class to the database class.
I guess that's where O/R mapper come in handy? Until now, I haven't realized their purpose, but I think I just found it. I've recently tried out using the new Entity Framework with .NET Framework 4, but I'm only using it like the Linq-To-SQL DataContext.
Is there a way to achieve the mapping automatically? If yes, is that something the new Entity Framework provides or do I need to look for a O/R Mapper like NHibernate?
I use NHibernate exclusively in my projects. I like the control and flexibility it gives me. There is a 'shortcut' called Active Record that uses NHibernate under the covers but provides a really nice an simple interface to NHibernate.
NHibernate has a steep learning curve, but when you get past that - it is really smooth sailing. When (and if) you venture the way of NHibernate, check out Ayende for cool tips.
(Entity Framework is an O/R Mapper.)
If you're serious about getting your hands dirty with ORM (but relatively new to that area), I highly recommend something like TekPub's videos on these topics. You'll be able to see these tools in use starting from scratch. It is a graceful introduction to some simple, but real-world issues like the ones you mention.
LinqToSql is an ORM, so you are already using one. Taking LinqToSql out and replacing it with EntityFramework or NHibernate won't solve the problems you appear to be having right now.
Here are some things you should learn more about to help give you additional context:
AutoMapper
Data Transfer Objects (DTOs)
Plain Old CLR Object (POCO)
I've had a great time using Entity Framework 4.0 (+ the CTP). I think you'd have a much easier time dealing with an ORM like that. EF4 provides everything you need to interoperate with MSSQL from C#/.NET. You won't have to write a single line of SQL, and it has full support for LINQ (through ObjectQuery).
When I last worked in programming, we were trying to move away from DataReaders and the traditional ADO.NET API toward Object Relational Mapping (ORM).
To do this, we generated a DataContext of our DB via sqlmetal. There was then a thin data layer that made the DataContext private, and any code needing to access the database would have to use a public method in this thin data layer. These methods were basically stored procedures; they would perform queries on the database via LINQ to SQL.
Is this a common approach today? I mean, is everyone whose using the .NET 3.5 framework really running sqlmetal in their build process, or what? It almost seemed like a hack at the time.
Basically, I'd like to know if LINQ to SQL and sqlmetal is what to expect if I'm go to write a DAL today at a .NET 3.5 shop that doesn't employ a third-party, open-source ORM.
It is still considered best practice to have some sort of data access layer. Whether this is best achieved with a ORM is a heavily debated issue. There is one faction that generally argues that ORM's are the way to go. Another faction argues that stored procedures and database centric is the best route.
Also, this may not be exactly the poster you meant, but it similar (and also the one in my cubicle)
http://download.microsoft.com/download/4/a/3/4a3c7c55-84ab-4588-84a4-f96424a7d82d/NET35_Namespaces_Poster_LORES.pdf
Your approach is good. I currently use Astroria services (ADO.NET Data Services). There was a nice introduction in MSDN Magazine about this.
I also like the new PLINQO (requires CodeSmith Tools though). This is very slick in my opinion.
When I have such a DAL (service layer), I just consume this service from my client application (Silverlight or ASP.NET MVC).
I think it depends on your use but I'd say with such a thin data layer as you explained that would be your DAL. Most projects will build another layer on top of that mainly for edit/create logic and maybe some stitching logic for gets.
For most of my projects I design it like this.
Repository holds the instance of DataContext and exposes some basic add/delete methods
ProductRepository : Repository exposes general queries (IQueryable)
StoreService uses an instance of different repositories like ProductRepository, SalesRepository and handles all logic for creating something like a product.
So something like...
StoreService.CreateProduct(/* properites */)
This would return some sort of result class.
The best data layer is the one that is plain and simple and gets the job done without any bells any whistles. I have used the technologies you mentioned and written about them here:
The Only Pattern for Data Access is - There Are No Patterns for Data Access
This very site uses LINQ to SQL, so take that as you will.
Officially, Microsoft is supporting Entity Framework over LINQ to SQL in terms of new development. However, there's a vocal group of people who think EF is the wrong way to go. LINQ to SQL will still be around for some time, and is a very decent ORM, if somewhat limiting in terms of which DB backend you can use.
I would recommend LINQ as a great starting point for your ORM. If you need better, look into EF and/or NHibernate.
"Is this a common approach today? I mean, is everyone whose using the .NET 3.5 framework really running sqlmetal in their build process, or what?"
The people I know using the 3.5 Framework (and that's just about everyone) - the vast majority - are still using NHibernate. Version 2.0 is a very nice OR/M. I started using it on a recent project and it cut my data access code down significantly, to the point where I really don't want to use anything else in the future. And the Fluent NHibernate API is making some headway for folks who don't like the XML mapping.
I've been programming in C# 2.0 WinForms for a while now. I'm starting to get into ASP.NET and the new MVC framework and the new features of C# 3.5. I've only read a little on LINQ to SQL but have made a few test apps to try it out. In my WinForms apps, I usually had some sort of data access layer, and wrote all the SQL myself. Of course, if something can do that CRUD for me, I'm all for it.
I followed the tutorials on the www.asp.net/mvc website and did both the Entity Framework example and the LINQ to SQL example. So far, they both seem pretty similar. LINQ feels more like SQL, but the Entity Framework feels more like C#.
My questions are:
Is one method better than the other?
What are the benefits of one over the other?
Is it possible to see the SQL that is generate when using either of the methods?
Since I'm new to the ASP world, are web developers leaning on one side?
2: LINQ-to-SQL has the benefits of being simple (but still well engineered) - but the downside of being simple ;-p
LINQ-to-SQL only works on SQL Server (Entity Framework is pluggable; 3rd party variants of LINQ-to-SQL like DBLinq cover some other providers)
Entity Framework supports more abstraction between the data (storage) model and the object model - LINQ-to-SQL is literal table/column => class/property[|field]
LINQ-to-SQL is actually more "complete" in the stuff it does do:
EF doesn't support UDFs
EF doesn't support things like sub-expression invoke (for custom expression trees)
EF doesn't support some "obvious" methods like Single()
EF doesn't have some of the TSQL optimisations that LINQ-to-SQL uses
Basically EF at the moment is a bit more of a "v1" (or even "v0.9") product. However (and importantly) - EF is likely to have a proper next version in .NET 4.0 etc, where-as LINQ-to-SQL is going to see a lot less change. It is still being maintained, but famously Microsoft have chosen Entity Framework as the flagship product (rather than co-evolve both products essentially into each-other). You should think about the long term plans.
At the moment, I'm very happy to use LINQ-to-SQL, but EF is on the long term... so I'm using repository etc to hide some of the gory implementation details - a bit of a leaky repository, but pragmatic.
3: With LINQ-to-SQL, assign a TextReader to dataContext.Log; Console.Out works well - or I have one that writes to the trace.asax. With EF, ToTraceString.
4: I suspect it breaks down a lot by complexity. People using SQL Server with simple models, or who are happy to have a storage model that shines into the object model tend to be using LINQ-to-SQL at the moment (from what I see). People with more complexity and other databases tend to use NHibernate ;-p And then some EF. I'm wondering how much this will change when EF is next released in .NET 4.0...
Use the one that feels best for you, your team and your project. It doesn't really matter how you access the data, as long as you access it.
You could use plain old ADO.NET if you want.