Tough Architecture Choice

As usual there's a time crunch.

There are two teams working on a Windows app and a Web app respectively. As it happens, both apps are supposed to converge, but the teams have been using their own database designs. So now I am saddled with two separate databases which need to be combined into one so both the Windows app and the Web app use the same/common database.

The database design is now in its first draft and there will likely be minor revisions in the near future (like a month).

I also have to decide how the apps will access the data.

Here's what I have in mind:

Use ADO.Net Entity Framework as the DAL for the new database: fast to develop and update in case my database design changes. Also strongly typed, so any changes to the database design should be caught in compilation of the code.

Use service classes which have Add/Update/Delete/Get methods for each of the tables/entities: Common interface and reuse potential. Both the Windows and the Web apps can use them for accessing the data. Unit tests can be written against them, and in future we can also write webservices to expose these classes/methods to external applications.

Rewrite the DAL interface part of the Windows and Web apps to use the service classes and the ADO.Net Entities


Are there any better ideas? Please note, I am not currently considering nhibernate or other similar ORM tools which will have a steep learning curve, as I have to roll out the changes by this month end.

btw, the existing structure is hapzhard as you might have guessed. The Windows app uses a lot of stored procedures for basic CRUD work as well as other data intensive processing. There's no middle layer per se. The web application goes a step further by directly using inline queries.

.

HB,

That sounds like an excellent approach. I would do the same - develop a SIMPLE access layer and deploy it as an assembly that can be used by both "sides" of the project. I agree, too, that using stuff like nHibernate would be an overkill, in the best of situations. It's always advisable to keep things as simple as possible.

I couldn't add much to what you've already said. You're thinking clearly.

At-least they're both using .Net (right?). That was a good choice to start with. Doing separate DB designs was a screw up but it sounds like you've worked out a way to mitigate that.

-Max

Yes, both apps are on Dotnet, and what's more, the same version too! *sigh* I never imagined I would have to use that line as a merit, but there we are.

.

Sounds a lot like a previous job of mine... only we had 20+ systems to contend with, some of which kept their data in the databases of other systems.

Sounds like you have a plan at least.

That last line in the first post though gives me the willies...

-tg