. Net project hierarchy and folder structure Daquan (best shelf Award, sputation Award, Yin Gou ship captioning Award announced)

 

An architect installed with X can highlight your dog eyes by creating folders...

--Legendary string brother

 

So far, the best shelf Award: the temple knight !!!

Reason:

Old Oil strip, nothing to say... the layered description is very accurate.

In particular, the understanding and description of WebModel (ViewModel) are in place, avoiding the suspicion of the design transition of ViewModel. If you have a designViewModel ....

Unfortunately, there is a lack of description on the data access layer, and I don't know if it will be dumped...

 

01. User Interface is the UI Layer. As the Interface for data input and display, this layer is an effective way to interact with users, so it plays a vital role. The first impression is the UI Layer, which must be considered based on different technologies or requirements during design. Generally, the UI can be divided into B/S UI, C/S UI, and WEB Service. Here is our ASP. NET project.

02. WebModelCommon: This layer serves as the middle layer of UI and domain logic. It serves as a bridge, filtering, filtering, and verification. It mainly includes two projects. WebHelper mainly provides some common operations for the UI. WebLogic converts, filters, verifies, and filters UI and domain logic data.

03. Business Logic: Domain Model (Data Model Layer) is always the core of an application and requires a lot of effort to perform OOAD-based analysis and design) best practices are designed and developed in accordance with OOP.

04. FrameWork: It mainly includes basic or common functions such as data access FrameWork, general permission FrameWork, exception and log processing FrameWork, IOC FrameWork, and AOP FrameWork.

05. SOA: This layer is not mandatory and can be selected based on the specific circumstances of the project. If the business is complicated and there are many interactive projects, SOA can reduce our burden; if the business is relatively simple, you can directly call or use Web Service/Remoting/WCF as the communication framework. In the process of implementing SOA, you can use WCF + WF to build a small and lightweight SOA framework, or use software such as Biztalk.

06. Reference: This section describes third-party frameworks and component projects. These files are stored in this directory in different categories.

07. Solution Items: project specifications, processes, and important documents.

08. Test: Some information required for the Test, such as the Test version and Test document, is placed here.

09, Publish: this folder mainly contains the released version.

The author's speech: Are there any prizes? In fact, this architecture is a little more complex (considering frequent expansion and upgrades). If it is a small project, there is no need to do so. At that time, it was to support multiple countries and devices. For example, the same project could automatically address access in Singapore and the United States based on different IP addresses. At the same time, there were two sets of routes based on different devices, mobile users navigate to the mobile website page, and PC users are on the normal page. There is an adapter for the data access layer. You can select an ORM through configuration (a set of class libraries written by yourself, encapsulated in the Framework) it is also a classic method (SQL and stored procedures are all written in XML files separately and called by reading XML files, which makes maintenance and version upgrade easier, at the same time, in order to reduce the system load and improve the user's response capability, we use MSMQ and SSB to organize message queues ). In addition, the data layer has Mock data for testing, which ensures that the project expansion and upgrade result in dependency and consumes too much time and effort. If you have time, you can write an article to discuss it!

Reply to comments:

Prize is required. Write a detailed article on this architecture and add the source code.

Small projects do not need to be so complicated. You can refer to the "real-time combat school" in the post. I think that layer is quite real.

Mock data for testing is a good way to introduce some good Mock frameworks.

Best sputation prize: [Qin shiyue]!

He is only a faint commentReplied"In fact, I just want to say that everyone is in disorder .". Come gently, leave no shelf. But string brother won't let him go ......

As a result, he searched for his blog http://www.cnblogs.com/humble/and found that he actually has an architecture."Moon. ORM"," Qin. Data "(andThe name Qin shimingyue echoed in the eyes of the young man of Literature and Art)......

In fact, what I want to talk about is whether it is the so-called "Avenue to simplicity"Qin shimingyue, Or mainstreamThe temple server guard can be said in terms of technical implementation.All things lead to Rome... right or wrong...

But in realityThe path of the anchor can be used to provide training for enterprises.The bright moon in Qin Dynasty may be more self-defeating. The reason is that you can discuss it...

 

 

Gutter captioning Artech:

Description: The solution structure of an instance in my comprehensive analysis of WCF. The basic idea is: first module (here refers to the coarse-grained module, which can be regarded as a subsystem) (two business modules: products, Orders, a non-business module: Infrastructure), post-level. Products. BusinessEntity: defines the Business Entity type provided. In general, the business entity and data contract are different. For the sake of simplicity, we not only combine the two, but also use the business entity as ASP. net mvc Model use; Products. dataAccess: the data access layer, which simply provides access to the database. This project has a project reference for Products. businesstity; Products. BusinessComponent: it can also be called the business logic layer. The real business logic is implemented here. This project has project reference for Products. BusinessEntity and Products. DataAccess; Products. Service. Interface: the contract Interface of the WCF Service is defined here. This project has a project reference for Products. BusinessEntity; Products. Service: defines the Service that implements the Preceding Contract interface. This project has. service. interface, Products. businessEntity and Products. businessComponent project reference; Products: provides basic functions for this module, including not only service calls, but also some necessary logical processing. This project has project reference for Products. BusinessEntity, Products. Service. Interface, and Products. Interface. Products. Interface: the Service Interface provided by the module to other modules. This project has a project reference for Products. BusinessEntity. Comments: Artech is a big guy in the garden. It seems that there are still books, but this shelf is a little unexpected. There are some questionable questions: 1. from the name on the shelf and the big body structure, we can see that it is the DDD, and the specific implementation of data access in DDD (that is, the DataAccess in the clip) it should be placed on the Infrastructure layer (the Infrastructure in the clip), while Artech seems to only use Infrastructure as the Framework for "non-functional requirements. Calling the Infrastructure "non-business module" seems to be a bit out of the box .... 2. products. the business logic layer of BusinessComponent directly references Products. dataAccess is also a serious problem. If DataAccess has no interfaces, the business logic layer depends on the data access layer. In the Enterprise Architecture Design of DDD and Uncle Martin, is an anti-pattern !!!, If there is an interface in DataAccess, the interface of DataAccess should be placed in the business logic layer, and then used through reverse dependency, and the specific implementation of DataAccess is placed in Infrastructure. 3. If the WCF is not used, I agree that DTO can be omitted, but the WCF on the shelf also combines DTO and PO into one, which I highly disagree. 4. The boundaries between the Products layer and the Products. BusinessComponent layer are unclear. As described by Artech, business logic can be put in both layers, but two modules are described. In addition, we can see that Products. BusinessEntity is still a blood loss model. This design is completely confusing. The Products layer I guess is a bit of the meaning of the Application layer in DDD, But what Artech does is obviously wrong. In short, I feel that this shelf has a large number of components, its ideas are very unclear, its naming is very nonstandard, and its standards are not good. The author's speech: Thank you for giving me this award :) 1. My main consideration for this structure is modularity rather than hierarchy. Or divide the layers based on the modules. 2. The module focuses on functions, and encapsulates business and non-business functions. I advocate offering external services at the module level, rather than offering external services at the level. 3. hierarchies are the hierarchies of modules to implement their own functions. Therefore, there is no need to define interfaces for each hierarchies. DataAccess provides interfaces to isolate data storage and supports multiple data storage methods. In fact, many functions similar to DbHelper can be provided. Therefore, I do not like to define interfaces for DataAccess. Although PetShop does this, many projects do the same. I still feel ugly. 4. An interface is a contract and a "service" interface. An interface must be defined only when the service is provided externally. An interface must be defined only when one module provides services for another module. 5. Because of the use of WCF, we adopt the SO design, that is, to provide an ideal granularity for sharing functions through the WCF Service, while Business is to implement services, it does not need to be too tightly coupled with the Service. Do not forget that the Service is exposed and consumed by Service Contract. 6 ,... reply: 1. the core of the architecture is the hierarchy, and the Division of functional modules (packages) is not the key; 2. if the business logic layer is dependent on the storage layer (DataAccess), data storage cannot be isolated. Without defining interfaces for the storage layer and adopting Dependency inversion technology, the dependency on the storage layer of the business logic layer cannot be removed. petshop is not discussed. the self-implementation of a module is no problem with the design of external interfaces, but it is not related to the business logic, but a very thin interface; 4. a coarse-grained service that truly implements SOA cannot be implemented at its own shelf level. More importantly, it relies on SOA middleware Products of large manufacturers. Is SOA used? In addition, I would like to thank Artech for its contributions in terms of WCF, saying that it was still difficult for me to read WCF. It was just as clear as I saw your post.

 

Let me start with the following:

The legendary string brother:

Tips:

1. The "solution folder" helps you plan the project structure well.

2. Add numbers 1, 2, 3, 4... to the solution folder to sort projects in the order you want

3. company name, project name, package name, and schema name naming conventions make your project structure clearer.

4. The number of sub-items should be based on the project's specific situation and architecture design. If the compilation speed is too slow, it will be troublesome to use.

 

 

Yiqing:

Comment: A relatively simple blog website uses MVC, and its naming is more standard.

Suggestion: the Controller and Model can be proposed from the website project.

 

 

Xu_happy_you:

Comment: The typical Petshop control, BLL + DAL + MODEL + three-tier architecture of the website, uses the factory mode to call the DAL

Suggestion: Try DDD and replace the factory mode with DI dependency injection.

 

 

A hierarchical demonstration project developed by Microsoft Based on the DDD architecture, NLayerAppV2:

Download URL: http://microsoftnlayerapp.codeplex.com/workitem/6687

 

 

Microsoft's CRM Project:

Download URL: http://orchard.codeplex.com/

Comments: Nima's score is too much ............

 

 

. Net's famous CMS, DotNetNuke (DNN ):

Download URL: http://www.dotnetnuke.com/

Comments: I think most of them are quite good, with reasonable division and clear structure. That is, there are so many solutions folders in "Providers !!!

 

 

The notorious PetShop4.0:

Comments: Over the years, many ignorant cainiao have been poisoned, and many projects have been built with X bricks... and projects with java testing efficiency. Have you studied the architecture?

 

 

First-line coders:

Comment: This Code allows the farmer to get a glimpse of the door path, naming rules, reasonable and clear structure ,. test is a bright spot. It indicates that it has already been used by DDT, which is worthy of praise. However, it is a little too detailed...

Suggestion: the pinyin "ZhuangHuang" will immediately lower the grade. It is recommended to change it to English and install X !!! No !!! Decoration... dierret... decorate

 

Jaws:

Comments: The naming method of lower case and abbreviation looks a little fresh, like the habit of java, say! Are you doing anything over there !!

Suggestion: Is it necessary to divide CSS, JS, and JSON into separate projects? Just like DNN ....

Nature of Tao:

Comments: from all aspects, it is impeccable and professional. The plug-in-based design tests your skills ?!!!

Suggestion: provide the source code for the majority of children's shoes to learn...

Soul light:

Comments: from Visual Studio in English, we can see that this person is better than me to install..., using WCF to implement distributed architecture, accurate and professional naming, and clear and reasonable structure.

What is commendable is that there is no trace of CAPTCHA, but the design and pattern ideas are everywhere. Identify as a master ..

Suggestion: You have checked out so many projects that others want to add files !!!

Liu Haichuan:

Comments: fake pictures and tigers are rare.

Suggestion: learn more from the person upstairs... start with Visual Studio in English !!!~~~

Kiler:

Comments: real combat !! Public class + business logic + database access + entity + website. The hierarchical objective is clear and straightforward, and there is no redundant design or pretentious naming.

Suggestion: In addition to practice, you can also look at some classic design and architecture theories.

 

Double-click:

Comments: I am curious about what is in Component when I stick to shelves and do not forget to post advertisements...

Project URL: http://www.jielongdaquan.com/

Liu Liuying Xia:

Comments: The naming of Petshop is a little treasure, but there are some trendy design ideas.

Suggestion: The interface should be discussed separately. Let's take a look at Uncle Martin's dependency reversal and have a deep understanding.

If models are divided into PO, ViewModel, and DTO, are there any design transitions?

 

Forest Space:

Comments: The high handsome and rich Camstar, DesignerClient in hand, the others are floating cloud ..........

Some friends in the garden:

Comments: From the Perspective of the shelf, the skill is solid and the design is old. But it's not a storm .....

 

 

Paladin:

01. User Interface is the UI Layer. As the Interface for data input and display, this layer is an effective way to interact with users, so it plays a vital role. The first impression is the UI Layer, which must be considered based on different technologies or requirements during design. Generally, the UI can be divided into B/S UI, C/S UI, and WEB Service. Here is our ASP. NET project.

02. WebModelCommon: This layer serves as the middle layer of UI and domain logic. It serves as a bridge, filtering, filtering, and verification. It mainly includes two projects. WebHelper mainly provides some common operations for the UI. WebLogic converts, filters, verifies, and filters UI and domain logic data.

03. Business Logic: Domain Model (Data Model Layer) is always the core of an application and requires a lot of effort to perform OOAD-based analysis and design) best practices are designed and developed in accordance with OOP.

04. FrameWork: It mainly includes basic or common functions such as data access FrameWork, general permission FrameWork, exception and log processing FrameWork, IOC FrameWork, and AOP FrameWork.

05. SOA: This layer is not mandatory and can be selected based on the specific circumstances of the project. If the business is complicated and there are many interactive projects, SOA can reduce our burden; if the business is relatively simple, you can directly call or use Web Service/Remoting/WCF as the communication framework. In the process of implementing SOA, you can use WCF + WF to build a small and lightweight SOA framework, or use software such as Biztalk.

06. Reference: This section describes third-party frameworks and component projects. These files are stored in this directory in different categories.

07. Solution Items: project specifications, processes, and important documents.

08. Test: Some information required for the Test, such as the Test version and Test document, is placed here.

09, Publish: this folder mainly contains the released version.

Comments: Old Oil strip, nothing to say... the layered description is very accurate.

In particular, the understanding and description of WebModel (ViewModel) are in place, avoiding the suspicion of the design transition of ViewModel. If you have a ViewModel design .......

Learn more address: http://www.cnblogs.com/KnightsWarrior/archive/2010/12/09/1900832.html

Suggestion: Open the source ..........

Artech:

Description: The solution structure of an instance in my comprehensive analysis of WCF. The basic idea is: first module (here refers to the coarse-grained module, which can be regarded as a subsystem) (two business modules: products, Orders, a non-business module: Infrastructure), post-level. Products. BusinessEntity: defines the Business Entity type provided. In general, the business entity and data contract are different. For the sake of simplicity, we not only combine the two, but also use the business entity as ASP. net mvc Model use; Products. dataAccess: the data access layer, which simply provides access to the database. This project has a project reference for Products. businesstity; Products. BusinessComponent: it can also be called the business logic layer. The real business logic is implemented here. This project has project reference for Products. BusinessEntity and Products. DataAccess; Products. Service. Interface: the contract Interface of the WCF Service is defined here. This project has a project reference for Products. BusinessEntity; Products. Service: defines the Service that implements the Preceding Contract interface. This project has. service. interface, Products. businessEntity and Products. businessComponent project reference; Products: provides basic functions for this module, including not only service calls, but also some necessary logical processing. This project has project reference for Products. BusinessEntity, Products. Service. Interface, and Products. Interface. Products. Interface: the Service Interface provided by the module to other modules. This project has a project reference for Products. BusinessEntity. Comments: Artech is a big guy in the garden. It seems that there are still books, but this shelf is a little unexpected. There are some questionable questions: 1. from the name on the shelf and the big body structure, we can see that it is the DDD, and the specific implementation of data access in DDD (that is, the DataAccess in the clip) it should be placed on the Infrastructure layer (the Infrastructure in the clip), while Artech seems to only use Infrastructure as the Framework for "non-functional requirements. Calling the Infrastructure "non-business module" seems to be a bit out of the box .... 2. products. the business logic layer of BusinessComponent directly references Products. dataAccess is also a serious problem. If DataAccess has no interfaces, the business logic layer depends on the data access layer. In the Enterprise Architecture Design of DDD and Uncle Martin, is an anti-pattern !!!, If there is an interface in DataAccess, the interface of DataAccess should be placed in the business logic layer, and then used through reverse dependency, and the specific implementation of DataAccess is placed in Infrastructure. 3. If the WCF is not used, I agree that DTO can be omitted, but the WCF on the shelf also combines DTO and PO into one, which I highly disagree. 4. The boundaries between the Products layer and the Products. BusinessComponent layer are unclear. As described by Artech, business logic can be put in both layers, but two modules are described. In addition, we can see that Products. BusinessEntity is still a blood loss model. This design is completely confusing. The Products layer I guess is a bit of the meaning of the Application layer in DDD, But what Artech does is obviously wrong. In short, I feel that this shelf has a large number of components, its ideas are very unclear, its naming is very nonstandard, and its standards are not good.

 

Everyone also posted their replies, And I sorted them out in the posts to learn and make progress together.

Everyone also posted their replies, And I sorted them out in the posts to learn and make progress together.

Everyone also posted their replies, And I sorted them out in the posts to learn and make progress together.