Came across this:
http://www.eggheadcafe.com/articles/adonet_source_code_generator.asp
And wondering if this is the right solution as I am not that big of a fan of creating a class for every stored procedure or do I use Enterprise Library for ASP.net 2.0 project.
You definitely shouldn't be creating a class for every stored procedure. There are a number of approaches you can take to handling your database interactions. You should have a good look at the major frameworks out there and decide which one best suits you. The Castle Project solution is great, and relies on nHibernate (nHibernate). LINQ is a similar offering by Mircrosoft (LINQ Project). Both of these solutions are full ORM frameworks (Object Relational Mapping) and will generate dynamic SQL to persist your objects in the database. Each also has it's own quirks and likes you to structure your objects in particular ways. If you don't want to manage the SQL your system uses, I would definitely recommend one of these approaches.
I come from a database background, and prefer a bit more control over my SQL. In particular I like to have my interractions handled by stored procedures. I find this enables me to control both the SQL better for optimisation, but helps me manage database security in a more friendly manner. To accommodate this approach, I recommend something like iBatis (iBatis). iBatis isn't a full ORM, but rather a simple SQL mapper. The downside to my approach is that you need to write a lot more code (SQL), but I don't mind the trade-off.
Is there any possibility of upgrading to framework 3.5? if so take a look at LINQ to SQL and Entity Framework as this will accomplish alot of this for you.
If not then as long as it generates standard code that doesnt tie you into 3rd party libraries then you could certainly use it. At my workplace we have our own generator similar to this and it works well although we will shortly be moving to LINQ to SQL.
There are many ways of wrapping a database table in a C# class; you probably want to investigate a few alternatives before choosing between the one you've linked to and the Entity Framework.
There's a software pattern called the "active record pattern" which describes exactly this approach - one C# class for each table, with load/save methods like Customer.GetById(), Customer.Save(), and so on.
For ASP.NET 2.0, check out the Castle Project's ActiveRecord implementation and a third-party Visual Studio plugin tool called ActiveWriter that lets you generate class wrappers for your tables using a drag'n'drop interface.
You will need to determine at what point you need sets of data that are composed from your tables, and whether you want SQL to produce these with stored procedures or if your business logic layer will handle these. As Dr8k says, nHibernate will create SQL for you, but there is a learning curve with nHibernate. The ORM will be in control of how you are getting the data and depending on your environment and DBA's conmfort level you may other issues to overcome.
If you more comfortable with SQL, then there is another tool called SubSonic that will create wrappers ala Active Record for you while offering you the ability to use stored procedures as well. There is also a nice query tool with a fluent interface that you can use if you are not able to use LINQ.
Related
I'm getting ready to start a C# web application project and just wanted some opinions regarding pulling data from a database. As far as I can tell, I can either use C# code to access the database from the code behind (i.e. LINQ) of my web app or I can call a stored procedure that will collect all the data and then read it with a few lines of code in my code behind. I'm curious to know which of these two approaches, or any other approach, would be the most efficient, elegant, future proof and easiest to test.
The most future proof way to write your application would be to have an abstraction between you and your database. To do that you would want to use an ORM of some sort. I would recommend using either NHibernate or Entity Framework.
This would give you the advantage of only having to write your queries once instead of multiple times (Example: if you decide to change your database "moving from mssql to mysql or vice versa"). This also gives you the advantage of having all of your data in objects. Which is much easier to work with than raw ado Datatables or DataReaders.
Most developers like to introduce at least one layer between the code behind and the Database.
Additionally there are many data access strategies that people use within that layer. ADO.NET, Entity Framework, Enterprise Library NHibernate, Linq etc.
In all of those you can use SQL Queries or Stored Procedures. I prefer Stored Procedures because they are easy for me to write and deploy. Others prefer to use Parameterized queries.
When you have so many options its usually indicative that there really isn't a clear winner. This means you can probably just pick a direction and go with it and you'll be fine.
But you really shouldn't use non-parameterized queries and you shouldn't do it in the code behind but instead in seperate classes
Using LINQ to SQL to access your data is probably the worst choice right now. Microsoft has said that they will no longer be improving LINQ to SQL in favor of Entity Framework. Also, you can use LINQ with your EF if you should choose to go that route.
I would recommend using an ORM like nHibernate or Entity framework instead of a sproc/ADO approach. Between the two ORMs, I would probably suggest EF for you where you are just getting the hang of this. EF isn't QUITE as powerful as nHibernate but it has a shorter learning curve and is pretty robust.
I have completed a simple database for a project. Only 6tables. Of the 6, one is a "lookup" table.
There is one "master" table that is the driver for the system. It is referenced as a foreign key by the other four tables.
Give that this step is completed. What is the FASTEST, EASIEST way to create POCOs/BizObjects that can load load the data and the child data.
Here are my CAVEATS.
I don't want to spend more than 30-60 minutes learning how?
There is very little biz logic needed in the POCOs. They will pretty much load data. Don't even really need to write back data.
I already know CSLA (up to version 3) but I feel that is overkill for this little project.
Nevertheless, I would love it if it ROOT objects could have collection classes that contain the CHILD objects as in CSLA...but again, without using CSLA.
Please give the answer for .NET 35 but also if I was restricted to only use .NET 20.
Ideally I could just point a tool at the database and the POCOs would be genn'ed.
FREE
Just curious what you guys use for this kind of scenario.
I understand that this question is subjective but I want to hear a variety of answers.
Seth
My choice would be linq-to-sql using sqlmetal to generate the code from the database.
Sqlmetal is a command line tool that generates classes for the database without customization. The advantage compared to the linq-to-sql designer is that you can easily rerun the tool to regenerate the classes if you have any changes to the database. Using the designer there is always a risk that the code isn't updated to match the database.
Use an ORM like nHibernate, SubSonic, Linq to SQL or Entity Framework.
They will all generate classes for you and a data layer.
The fastest to get up and running would be Linq to SQL, as it is built into VS 2008 (point to a SQL server, drag and drop, magic!).link text
For .NET 3.5, LINQ-to-SQL; drag the tables onto a data-context, job done. Actually any ORM would probably do, but LINQ-to-SQL is a very quick way of getting the job done using just the MS tools and VS IDE.
They aren't "pure" POCO done this way (they have L2S attributes etc), but it is easy. You can do pure POCO with L2S, but it takes a bit more effort.
With 2.0, NHibernate. But more work as unless you use additional tooling you'll have to write the classes and/or mapping files.
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
What is the best approach to build a small (but scalable) application that works with Sql Server or Oracle?
I'm interested in build apps that supports multiple databases, in the process behind the feature.
Using an ORM that supports multiple databases is the first step here. You could look at either NHibernate or Entity framework for example - both have oracle and sql server support. That way you should just have to swap out the database mappings to get the application to work on either DBMS.
Edit - thanks to tvanfosson, added the 'new' link for nhibernate.
In addition to the ORM comments; sometimes life is not that simple.
You must keep separate scripts for generating your tables, views, and stored procedures on both systems as they will differ.
You may have the need to do something tricky for performance reasons that is specific to one database platform. For example, making a new partition in Oracle.
You should try to do it at this level by encapsulating it in a view or stored procedure.
Your client code can call the stored procedure with the same signature on any database. You can write a stored procedure that does nothing or lots depending on what that databse requires.
My suggestion would be to use an existing (free) framework, like nHibernate, which abstracts out the dependence on the database for you. Alternatively, you'll need to define your own abstraction layer that is able to interact with drivers for either of the two databases.
as a complement to the other answers, you should tak a look at DbProviderFactories architecture in ADO.Net... a bit low-profiled but maybe useful for you.
As many people have pointed out, using an ORM could solve your problem. I've used LLBLGen with great success. Alternatively you can use the interfaces IConnection, ICommand and so on to roll your own ConnectionFactory.
I would use an OR/M. Most of these have support for many different database vendors and have a database agnostic language to do quering and the like.
I can recommend NHibnernate for C#.
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/