Question

I work for a company that develops a very large scale data based application. The application was first created around ten years ago and as such, is in desperate need of an upgrade. I have been given the task of investigating and implementing the data layer upgrade.

At present, it uses a system with business objects that are all based on/extend DataRow objects, that is – each object more or less relates to one row in a database. The application is NOT currently object oriented, but this causes many problems and we want to move in the OO direction.

So we are looking to start using the .NET `Entity Framework’ and create an .edmx file. The idea is simply to drag all of the SQL database tables onto the .edmx designer and let it create its related data objects.

Now in my mind (as an OO developer), I was planning to manually create new business objects and populate them from the .edmx generated data objects returned from queries in the new data layer. This would allow the simple separation of the various layers using an interface.

The problem is that the boss says that there is not enough time to rewrite the hundred or so business object classes and he suggests using the .edmx generated data objects throughout the whole application.

Every thought in my mind says ‘no… don’t create that coupling between the data layer and the whole system’, but the boss says that he has seen articles online promoting this.

So my questions for you guys are these: (please provide valid reasons for your answers to 1 and 2)

1. Is this a viable solution (even short term)?

2. Is there a better/alternative solution to creating separate business objects from the generated data objects?

3. Is there a better/easier way to create separate business objects from the generated data objects rather than manually copying and pasting?

I understand that these questions are somewhat subjective, but I’ve provided as much specific information as possible and I could really do with some advice on the subject.

Answer 1

This is one common issue happens to probably every legacy system people try to upgrade.

I don’t see any point that you create “hundreds” of business objects and copy data from EF data objects to yours? You are still coupling with a EF and your business objects!

To get passed with coupling IoC should be used where you can consider keeping the separation from your data access layer from your business layer. And definitely you can switch ORM with very little cost/time. This is the beauty of separation of concern.

In software industry, if you want to cut down the cost now, you probably have to pay more in the long run (if you need to change or ORM once again).

Try to negotiate with your boss in terms of quality, which maybe a bit costly now but definitely be gaining in the long run.

And in your case, you may consider EF Code First. This will definitely give you a better grip than “Database first” on your data access layer design.

You may also code generators to generate your data access layer like the way you want which will save hundreds of man hour, plus you can get a better implementation of your module. I would suggest you to go for CodeSmith Generator. There’s a bit of learning curve, but it’s worth it.

Please keep in mind separating the data access is not the solution to upgrade a legacy system. I have seen in many cases where upgrading and maintaining the core functionality becomes the hardest job in the world. And there’s nothing much to do unless the business people decides for a real upgrade when they face loses.

Try to identify the core components and DAL must be one of then to be upgraded.