Today, someone in the group made a post link: About Model data physical layer, welcome to discuss
content:
Model mapping database tables is an entity, when the system needs the emergence of new transformations, such as adding new features database need to add new fields,
or the need to remove and replace some of the old features, then the corresponding database field will certainly be modified. If the structure of the database table are converted,
a corresponding physical transformation certainly Model layer.
Change a field,
the Model layer must be modified,
then the DAL layer must be modified,
SQL statements must be modified,
represents the data presentation layer is also dependent on the attribute name of the Model layer, should also be amended.
This does not comply with Single Responsibility design pattern. Led by a launch body.
And so designed that with what design patterns are no good.
Secondly, the workload is very large, such as local commodity light table, then perform a query, it's terrible.
I ask you is how to deal with this problem, or how to minimize the impact.
Here are N number of posts to keep abreast of issues to discuss, but the substance has not made a fundamental solution, or like posts Azeri have to say:
2: modification of the demand for change is a model, not a database!
3: Open a specific criticism of what "database-driven thinking"
Of course, the original posted message was true also see the original paste.
Below this help :
No matter what the reason based on, or right or wrong, a prior database, then the entity the way, has been accepted by most people, and in this way has been engaged in related development.
How CYQ.Data framework to deal with change: a "how to minimize the impact" of
The introduction of enumeration and entity classes: deal with a
However, in order to facilitate the development, enumeration may be introduced with the entity, for all the articles in this framework, are introduced by way of enumeration, enumeration do not do so for more than introduced.
They say at how the introduction of entity classes can respond to change :
Such as the Users table:
{
public static int ID = 0;
public static string UserName = "UserName";
public static int Password = 2;
public const int CreateTime = 3;
}
Description:
Specifically how to deal with ?
If: Users will watch the UserName into MyName, of course, is the way to deal with change one line of code on the line, another call the same way:
Some people question: If the CreateTime into LoginTime it? You defined above is shaping Oh? Then you put into it:
Description:
If you increase the field, the same, then you add a static member attribute a.
Respond to two: the AutoSetPre cope with increased interface code update
If the wording is normal, we will assign to each property, such as before the update:
action.Set(Users.UserName, " 路过秋天 " );
action.Update( 2 );
action.Close();
If we try to use AutoSetPre way, the change to the foreground UI to go to the field and more, you can omit a lot of code such as:
action.SetAutoPrefix( " txt " );
action.Update( 2,true );
action.Close();
Description:
If at this time the database is modified to UserName MyName, only need to modify the name of the control to the foreground of the UI, UI modifications at least you do not have to re unravel the code.
Also for adding data, you only need to:
action.SetAutoPrefix( " txt " , " ddl " );
action.Insert( true );
action.Close();
The rest of the things, to the UI handled.
Respond to three: multi-table view and custom SQL queries
Custom multi-table SQL: SQL just need to customize the unified management of multi-table, or when performance is not required multi-select * way, you can avoid the field names appear, or appear, because unified management, you can easily modify and update individual unravel, of course, if you save it to call or map to xml, that can directly modify the xml, this is one way to deal with the.
Respond to four: the interface binding
Another way is automatically generated if the GridView column mode, you can not even UI are saved.
Last knot words:
If you have any questions, please leave a message.
Reproduced in: https: //my.oschina.net/secyaher/blog/274341