New Asp.Net MVC Project using Old BLL layer (classes + ado.net + SP)

Question

Here is the situation :

• I have an Asp.Net 3.5 website using a BLL project with object classes containing methods which call a DAL which call stored procedures (Oldschool)
• I am creating a new website (Asp.Net 4 and MVC 3) using the same Database and objects. I will also add a bunch of classes and new tables (a dozen I guess) which are related to the existing classes and tables.

My probleme is :

How can I make all this working together. I really want to use MVC for the new project, and make all working as proper as I can. The old project is a complete mess but it so huge that we can't touch it.

So how to handle the new object ? Use the same old method with classe and stored procedures ? Create a repository pattern for the new object and classes ? etc...

Thank you very much

ps : I don't know if I am clear but I can give you any other details if needed.

ps2 : I am not looking for coding solutions, but some indication of best method to follow for a smooth integration

Answer 1

You don't need to use the repository pattern, or EF, or DI, to use MVC. If your BLL is what you use to get your business objects (CRUD operations), there's no reason you can't use that directly in your controllers.

As far as adding new classes/tables, it depends on how tightly coupled your BLL is. If it's loosely coupled using interfaces it should be possible for you to use a different pattern for some DAOs, but if the DAOs reference each other directly it may be more trouble that it's worth.

If you want to go the extra mile I would say a good first step would be to define your CRUD operations in interfaces (if there are not interfaces already) and have yout BLL classes implement them so you can use DI and make it less painful when you do switch to a different DL strategy.

Answer 2

I am currently finishing the DataAccess layer on a project with EXACT issues and this is how I have solved it:

I've used the repository pattern to insulate my "new code" from knowing anything about the old code. In the repository I use calls into the existing logic to generate any of the "legacy" entities and use Entity framework to manage any new ones. Some entities require a "combined" approach to the CRUD operations. For example when I create a new User entity I need to call two different objects from the legacy system, the first returns me a PIN that I use to call into another legacy object to create a user instance and return an Id and that Id is finally used with the new Entity framework to manage the "newUser" part of the object. This data access layer is then exposed to the MVC project that only knows about the entities as the new system sees them and have no idea what the underlying legacy structure is. As such our MVC project (and even business logic layer in our case) is only aware of repositories and if we decide to move the legacy logic/CRUD operations to the new system, nothing will change but the actual repository. This makes for some rather "bulky" repositories in some cases (most complex is the one I mentioned about users), but gives a clean separation of new and legacy code.

I know that this is injecting some business logic into the data access layer, but for our project this was a deliberate choice due to other factors. You can have your business logic layer make the calls into the legacy layer if you want to.

Hope this has helped, in case it is not clear just let me know and I will explain further as it might not be as clear here as it is in my head :)