We Keep Coding

Creating a platform to handle CRUD scenarios for unknown entities

I want to create a platform that can read an XML or JSON configuration of entity names, their properties, and relationships and do basic CRUD operations on these entities as a starting point.
This means there will be no C# class definitions for these entities.
I would like to use a SQL Server database for this, however I believe it would be much easier to use something like a Graph or NoSql database since there is no predefined structure to create an ERD.
I would also like to use C#, Entity Framework, and JSON.NET to work with these dynamic entities and process business logic on them.
Another way of explaining it is the following:
Through a UI I would like someone to be able to do the following:
Create an Entity called Book.
A Book has the following properties: Title, Description, Author (one-to-one relationship w/ Author)
Create an Entity called Author.
An Author has the following properties: FirstName, LastName
What is a platform like this called and can someone lead me in the right direction?

What is a platform like this called and can someone lead me in the right direction?
Those applications are called Database Administration. Some examples are SQL Management Studio and PHPMyAdmin.
I want to create a platform that can read an XML or JSON configuration of entity names, their properties, and relationships and do basic CRUD operations on these entities as a starting point.
Why do you want to do it? We already have many application which has decades of developement efforts.
A quick search showed me a tutorial how to create one using ADO.NET. I haven't taken a closer look to it, but you can be sure, such an application is not as simple as following a tutorial.
I would also like to use C#, Entity Framework, and JSON.NET to work with these dynamic entities and process business logic on them.
Remember: Entity Framework is an ORM (Object-relational mapping tool). It's job is to high level map between your existing database and your application. You do not want to map your application code to a database, you want to administrate that database.
Therefore, EF is the wrong tool for the job. I think ADO.NET is the best you can do. You want to create a low level database application, so you need to use a low level tool.
That said, probably you want to just create some user defined content types? Then we are talking about a CMS. Probably you find some ideas in the Orchard Content Management System.

Recommendations for C# database access

Hi I've programmed a fair bit of C#, but never with a database. I'd like to use SQL Server with C# with some framework. Microsoft seems to have shipped a number of frameworks through the lifetime of C#. This makes it difficult for me to search/choose.
Which one should I choose? I'm developing a simple 3-tier webapp. I've watched a few Entity Framework .Net 4.0 videos, but I get the feeling that things are too automatic. I need to do some SQL now and then..
And if I should go for the EF4.0, is this really the best reference http://msdn.microsoft.com/en-us/library/bb386876.aspx
Any recommendations?

Go with Entity Framework 4 - it is the current and future best approach to SQL Server database. It is the basis for WCF Data Services, and the idea of a conceptual model will show up in other Microsoft product, for sure (Reporting Services and others, possibly).
And it does give you a lot of hooks to allow you to execute "on the fly" SQL statements, and you can also integrate stored procedures very nicely into Entity Framework.
And for the "run of the mill" everyday tasks, it gives you nice C# objects - based on your database - to work with.
In my opinion, this is your best choice currently - and the one with the most flexibility and options. You can start with a database ("database first") and create your classes from existing tables; or you can start with a model and have EF4 generate your database for you, and EF v4.1 (due out pretty soon) will also offer "code-first" development where you don't even need a visual model but you can describe all your database objects and settings in just C# code.
Update:
Entity Framework 4 Overview
Learn Entity Framework - the site accompanying the book by the same name, by Julie Lerman, Goddess of EF :-)
ADO.NET team blog with lots of good EF stuff
Entity Framework team design blog
ASP.NET 4.0 and the Entity Framework 4 - Part 1 - Create a Database using Model-First Development - good intro for EF4 model-first approach; Vince has multiple articles here - click on his name to get a list of all his articles (many new ones EF4 related)
Introduction to Entity Framework (this was for v1 - but still good)

C#+ActiveRecord+NHibernate. Hide the implementation behind several WCF services.

You said you want to try some 'framework', so Entity Framework is that one. It is the result from best practices MS come up with after years of research. Of course, on the way, you can always use SQL (Dataset) anytime you want together with EF (mostly for performance tuning).

I would say Start with Rob Conery's Sub Sonic..
Its easy to start with..specillaly Simple Repository..
Site Link: http://www.subsonicproject.com/
Simple Repository using Sub Sonic:
http://subsonicproject.com/docs/Simple_Repo_5_Minute_Demo
Update:
I have seen one answer mentioning NHibernate and want to add a small addition to the same... and since OP mentinoned that you have good experience with C# I assume you have good OOPS knowledge and also the relationships amongs objects
I personally felt much easy to start with NHibernate when used it with Fluent NHibernate hence I would also suggest
C# + NHibernate + Fluent Nhibernate....

Take a look here for some information about performance/benchmarks on various ORM frameworks for .Net.

How can I improve my business layer objects mapping into a database? Is it time for a O/R mapper?

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).

Create db schema from domain objects in .NET

In EJB 3.0 you can write your domain objecs, then convert them into entitities (adding #Entity attribute, etc.) and underlying JPA mechanism (let's say Hibernate) can automaticly generate db schema. What's better it will also update db when you update you domain model in Java code.
I'm looking for equivalent of that functionality on .NET platform. Is is possible with ADO.NET Entity Framework?

DataObjects.Net also automatically generates and upgrades database schema according to domain model. But the most interesting thing is how to upgrade stored data if model and database schema are changed. Is it possible to do it on entity level, rather then using low-level SQL?

Mindscape LightSpeed supports this - full schema round tripping with model first or database first development. It is a commercial product but there is a free version for small databases.
As mentioned, Entity Framework will add some of these features in their next release but that is some time away.
Details of the LightSpeed designer with the model first support

Active Record is the way forward! You mark up your objects with attributes and from there you can generate the database schema or the database itself. There is also a tool called Active Writer which allows you to draw the models and it writes the codes with the correct attributes for you.
It is essentially a wrapper for NHibernate but it makes things a bit easier as you do the mapping on the objects rather than in XML documents.
We have used this on several projects and found it to be a fast way of implementing complex systems.

Yes - in the future :-) The current Entity Framework doesn't support the "domain-first" approach - but the next version (EF v4) will. This will ship with .NET 4.0 / Visual Studio 2010 - but don't ask me, when! I don't know (neither does Microsoft).
Marc

NHibernate is a .NET port of Hibernate, and I think it includes tools for generating database schema for your entities.

There are third party frameworks that do this in .NET today.

.NET and database layers

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.