What components to use for ASP.Net Web site re-architecture

Question

I am tasked with re-architecture an existing ASP.Net 2.0 Web Site. The current solution has 3 projects; Web UI, Business layer project and Data layer project.

The Data layer uses some sort of SQL helper class and stored procedures to return DataTable.

The Business layer sort of passes the DataTable along, I don't see much business logic.

The UI web site is heavy on DataGrids.

While brainstorming, my thoughts are; I want to obviously keep the layered design and use the separation of code by using 3 projects in the solution.

The part that I am most confused about is the Data Layer.
What should I use for this part, Entity Framework, or create my own Classes that represent my database or logical objects? Speed of development is also an issue, it has to be down fairly quickly and be flexible or decoupled for enhancements.

I tried going the MVC route but the learning curve is too steep for the developers at this time. So, it has to be Web Forms. :-(

I am leaning on using Enterprise Library for Data access, logging, caching and Exception handling.

I am seeking suggestions and best practices.

Answer 1

I want to obviously keep the layered design and use the separation of code by using 3 projects

Why? Wouldn't it make more sense to start with the assumption that everything should go in one project until you can clearly identify classes which need to be separated?

Especially if you are using something like Entity Framework, nHibernate or LINQ to SQL - those libraries are your DAL.

The application I currently lead is comprised of 7 projects (not including unit test projects), but we didn't create the projects until we had concrete functionality which had a compelling, easily-articulated need to be in a different project. The distinction is important - not "you think it should" but "it must or certain things become very difficult or impossible". Otherwise you're building roads to nowhere and predicting they will meet traffic needs in 100 years.

Answer 2

I would rethink MVC. Any web developer should have a string grasp of standard HTML functionality, which MVC gets back to. As a webforms developer, I got going on MVC in a couple days and I will not go back!

Answer 3

This is how I would do it. I would re-architect everything first, from Data Layer, Views, Business Logic and Rules. Starting with the Data Layer see what I can reuse and see what I need to redo for performance and scalability. Having of course into account all my business logic and also the time I have to redo everything.

You can how ever Refactor your code if you have little time.

For the Data Layer you should check http://www.ormbattle.net I ended up buying LLBLGEN Pro since it's backend independent.

Answer 4

I recommend for you NHibernate or LINQ to Sql.Both are interesting and powerful.ADO.NET Entity Framework is also good.

Answer 5

You have been tasked with re-architecting the solution - why exactly? That should be driving your new architecture (to a degree at least).

So, two parts to this answer: the higher level stuff, then the specifics in your question.

What are the non-functional requirements? (also know as 'ilities' http://en.wikipedia.org/wiki/Ilities) or at least their relative priority?
Those should drive any architectural effort. Are we architecting for speed, availability, maintainability (for example)?

Regarding your specifics: as you say, doesn't look like there's much logic going on in the logic tier. Just passing through DataTables sounds ok for short-term limited use, but won't be practical in the long-term. If you're just pushing data (reports) through to be displayed then that's cool, I guess.

I've never used Entity Framework, nHibernate or LINQ to SQL personally, but any should work. They may have impacts in the dependency space (vendor lock-in, licencing, etc) - does that matter.

At the very least I'd want to abstract out the data access implementation behind an interface - that way it doesn't matter what you use.

Using the Enterprise Libraries is good, no point re-inventing the wheel if you don't need to.

Regarding speed of development: have a look at the kind of things you need to do with your DAL. For any new technology, do a prototype first, based on your most complex piece of functionality first. That should help you establish whether or not it's feasible given your time constraints.