Asp.Net Program Architecture

I've just taken on a new Asp.Net MVC application and after opening it up I find the following,

1. [Project].Web
2. [Project].Models
3. [Project].BLL
4. [Project].DAL

Now, something thats become clear is that there is the data has to do a hell of a lot before it makes it to the View (Database>DAL>Repo>BLL>ConvertToModel>Controller>View). The DAL is Subsonic, the repositorys in the DAL return the subsonic entities to the BLL which开发者_Python百科 process them does crazy things and converts them into a Model (From the .Models) sometimes with classes that look like this

public DataModel GetDataModel(EntityObject Src)
{
    var ReturnData = new DataModel():
    ReturnData.ID = Src.ID;
    ReturnDate.Name = Src.Name;

    //etc etc
}

Now, the question is, "Is this complete overkill"? Ok the project is of a decent size and can only get bigger but is it worth carrying on with all this? I dont want to use AutoMapper as it just seems like it makes the complication worse. Can anyone shed any light on this?

---

First, I think your reluctance to use AutoMapper is surprisingly illogical. I can see reasons not to bring in another third party library, but in this case AutoMapper really doesn't complicate things, as long as you hook it up correctly and in the right places (i.e. only one place...).

Secondly, the entire ASP.NET MVC Framework emerged from a wish to enable developers to build loosely coupled, scalable and "pluggable" applications. This does mean more work to do the same thing if you're going to choose one path and then go down that path, that's right. But as soon as you make a decision to change something - perhaps you decide to move from Subsonic to some other provider, or to use AutoMapper after all - you'll notice that you only have to re-write relevant parts of your application, instead of the entire thing.
(I'm not saying you have to rewrite a WebForms application from scratch if you for example switch database engine, but you'll have to look through almost all application code to update relevant parts of the code, if you haven't worked hard enough on decoupling. In which case you're not saving any work by choosing WebForms over MVC...)

In short: Yes, this means more work for you than just "hacking something together". And it does look more complicated than may seem necessary. But as soon as you start changing your mind about something (and you will) you'll praise your lucky star that you did it "the right way"* from the beginning.

*) There's no such thing. I know.

---

Now, the question is, "Is this complete overkill"?

Yes, it is overkill. Someone is trying to build an app that's 3-Tier/n-Tier and MVC, not realizing that depending on your point of view MVC is itself either one way in which one can build an n-Tier application, with each main/traditional tier already one part of the MVC acronym, or an alternative architecture that you use instead of n-Tier. Either way, seeing DAL/BLL classes along with MVC is just a little weird.

The other thing to remember is that you may not have just a web application. Sometimes there is a winforms "smart client" or other application that talks to the same database and is really part of the same system — for example, a consumer facing e-commerce site view and sales rep view of the same inventory database. In this case, a traditional DAL and BLL might be a good idea, because they can be shared among each of the different apps in the system. But if you're doing that you should probably look at a service layer instead.