Should i create the model classes based on the structure of data in Database?

I have predefined tables in the database based on which I have to develop a web application.

Should I base my model classes on the structure of data in the tables.

But a problem is that the tables are very poorly defined and there is much redundant data in them (which I can not change!).

Eg. in 2 tables three columns are same.

Table: Student_details
Student_id , Name, AGe, Class ,School

Table :Student_address

Stude开发者_开发百科nt_id,Name,Age, Street1,Street2,City

I think you should make your models in a way that would be best suited for how they will be used. Don't worry about how the data is stored or where it is stored... otherwise why go through the trouble of layering your code. Why not just do the direct DB query right in your view? So if you are going to create an abstraction of your data... "model" ... make one that is designed around how it will be used... not how it will be or is persisted.

This seems like a risky project - presumably, there's another application somewhere which populates these tables. As the data model is not very sound from a relational point of view, I'm guessing there's a bunch of business/data logic glued into that app - for instance, putting the student age into the StudentAddress table.

I'd support jsobo in recommending you build your business logic independently of the underlying persistance mechanism, and that you try to keep your models as domain focused as possible, without too much emphasis on how the database happens to be structured.

You should, however, plan on spending a certain amount of time translating your domain models into their respective data representations and dealing with whatever quirks the data model imposes. I'd strongly recommend containing all this stuff in a separate translation layer - don't litter it throughout the rest of the application.