Using a DataSet instead of custom business entities in soa and n-tier architecture

Question

I’m working on a large and a high volume transactional enterprise application which has been designed using n-tire application architecture .And it was developed in the .NET platform utilizing C#,VB.NEt, Framework 3.5, ObjectDataSources, DataSet, WCF, asp.net update panel, JavaScript ,JSON, 3rd Party tools. The application is supposed to accomplish a really scalable / easily maintained / robust application / integrations, and to make sure that my services are created using a format that can be understood by other systems.

The problem is, this application is about 70% complete but now I was wondering if the following would cause us future issues,

I’m using a DataSet and a DataTable to (get /set) the data (form /to) the stored procedure in the database using the ObjectDataSources and was wondering if this would prevent my application from achieving the above goals. Actually, I am not anti-OO. I write lots of classes for different purposes, but I didn’t use the entity objects(custom business entities) instead of the previous way because I have a large database that may contain 50 tables and I was just afraid to create entities for each table and then in the future if I need to change the schema of the database, it might cause a huge affect on the application ?

Answer 1

If you use Entity Framework, your entity model doesn't need to match your database schema one to one. That should allow you to keep your entity model stable as the database changes.

There are several issues with returning DataSet from a service. Among others, only a .NET client will understand it. There are others, including the fact that it is wasteful of space and usually includes the schema when it is serialized.