Can we use SQLMetal Objectmodel as application object model?

Question

Our team has just started using Sql Metal and I have been playing around with it for 2 days. While doing this, I have noticed couple of things.

1. When we run command like following

sqlmetal /code:ps.cs /server:devapp042dbs /database:promotionalsponsorship /namespace:DAL

It creates a "LINQ to SQL SQLMEtal" object model. Now, this is not our regular class. It has a lot of autogenerated code and it almost smells like LINQ/EF with a lot of autogenerated properties and methods.

I have used Micro ORMs like Dapper and ORMLite from Service stack and the onderful thing about those is that it works with the simple objectmodel that we have created rather than auto-generating its own object model.

My question is that can we use these SQLMetal mapping classes as our Models of the application or we have to create a simple wrapper class around it using which we can extract all the information that we need to.

To clarify my point following are the samples of what I call a SQL Metal Class and a simple model class

Answer 1

Although this question would possibly be closed, as the answer is subjective, the short answer is yes, it is perfectly valid to use such autogenerated set of classes as your model. There are plenty of succesful apps built this way.

Since these classes are partial, you can even extend your domain model by adding custom properties/methods/events.

If you are concerned that the autogenerated code is not clean enough, consider the code first approach of the Entity Framework, nHibernate or any other ORM that supports this scenario. This way you start from a clean POCO model and just define its mapping to a relational structure.