I have to admit that although I am very hard, I really want to be a architect and system analyst, and I am still a programmer. Whenever I am watching those software engineering or methodology, such as a "architecture" in the book name, there is a voyeur to read the Bible (or forbidden book). At the same time, I don't understand and I can't persist in it (such as the "enterprise analysis model" of this big cow "), I feel my heart, and the sky is justified. Martin Fowler's reputation has always been very good, and the company's application architecture model is a book, the book review of the Bear Festival is: in the name of beauty. I have to treat it with a film, I have read the book "Details", as for the reason I have now understood it, it is very difficult to understand, it takes me a week, usually. It is in the bed. I am first excited, like a state of chaotic state, the first priest of the simple agricultural uprising suddenly got a program manual that guided its revolutionary practice. I know, I have known that it is almost. Some entries and thinking are recorded below:
1 Layer refers to the logically "layer", and Tier is physically. Three Layer refers to a layer, a domain layer, and a data source layer. Hey, I used Delphi to participate in the MIS project of the three-layer structure, but it can truly understand it to extract "business logic" out of a single layer, or after entering J2EE. The familiar idiomp is well said, "Hand has a hammer, see what is nail," Delphi's strong visual environment, data perceived control (equally strong in .NET) makes programmers comfortable to intertwell business logic, happy. 2 Transaction Script - Using the process to organize business logic, each process handles a single request domain model from the performance layer. Now more or a transaction script, an important reason is that many programmers' thinking is still a deep-standing process-oriented process, of course, if business logic is not complex, use it is also completely reasonable.
3 Domain MODEL (domain model) - merged the domain object model of behavior and data. Through the collaboration of the interconnection to cope with extremely complex business logic, some object simulate data in business activities, and some objects are responsible for capturing business rules, data, and processing. Derivatives two, one is the simple domain model, almost every database table corresponds to a domain object. The other is a complex domain model, which is different from database design, inheritance, strategy, and other design patterns. In principle, the coupling between the domain model and the other layers of the system should be minimized.
4 Object Relationship Structure Mapping - A considerable number of books in the book is in terms of ORM theory, and the examples are also very understanding. It is easy to connect with project practice. Formerly walked, every reconstruction, from using JDBC packages to now Using open source frames ibatis (hibernate), you are looking at, you don't have your confirmation.
Identity Field Identification Domain - Save the Database ID domain to the object to maintain a correspondence between a memory object and a database row.
Foreign Key Mapping Foreign Key Mapping - A foreign key reference between an associated map between the objects.
Dependent Mapping Dependency Map - A class is a subclass for database mapping. Statute is not other owners for subclasses, usually using Lazy LOAD.
Embedded Value Introduction - Map an object maps to multiple domains of the table of another object, usually a small simple value object, such as Money and Range. Single Tale Inheritance single table inheritance - a inheritance of the class by a table Level, each column in the table corresponds to all domains in different classes of the inheritance hierarchy. Class Table Inheritance class inheritance - represents the inheritance level of the class, each class corresponds to a table.
Concrete Table Inheritance Specific Table Inheritance - Indicates the inheritance level of the class, and each particular class corresponds to a table in the level.
My preferred architecture should belong to the transaction script, consisting of the following parts: entity (that is, the object that requires persistence, may be "anemia domain object") is just the form of the original data, plus some of the simplest operations (only Simple processing involving its own data). DAO is responsible for transforming data into entity objects (for hibernate or ibatis). Business logic is placed in Service, each service method is a Transaction Script, which may not meet the business logic needs of special complex violent changes, or Domain Model, which can't be guilty, I think this is already very good. Ground is dealt. Later: The ancient object-oriented principle teaches us, to package the state and behavior of the class together, the teacher is natural, the avenue is simple, but the design model has complex the system, which will cause many people's doubts. The reason is this: The design pattern is to deal with "change". In order to meet the opening and closing principles in the OO principle, the design complexity and easy-speaking degree are usually inversely proportional, we must seek better balance points, art and reality balance point.
