用Visual C++創建WPF項目的三種主要方法

The problem with using XAML from C++

Because C++ doesn’t support partial class definitions, it isn’t possible to directly support XAML in VC++ projects using this mechanism. That isn’t, however, the core reason why VC++ doesn’t directly support XAML. In addition to using the x:Class attribute, you can also use the x:Subclass attribute so that the XAML gets compiled into the class specified by the x:Class attribute, and the code behind will define the class specified by x:Subclass, which will be derived from the x:Class type. Thus, the lack of partial classes isn’t that big of a block. The main issue is that, right now, no 100-percent CodeDOM support is available to convert

the XAML to C++, and that is the single biggest reason why VC++ doesn’t support XAML intrinsically. I don’t know this for sure, but it’s possible that on a later date, the Visual C++ team may work on their CodeDOM support and provide a fully functional XAML-to-C++ converter. Once that’s available, XAML support can be integrated into VC++ projects. As of today, however, that isn’t an option.

NOTE: CodeDOM is a term used to represent a bunch of types available in the System.

CodeDom namespace that lets you abstract code into an object model. Source code is represented using the CodeDOM tree and can be converted into source code for a specific language using the CodeDOM code generator for that specific language.

Still, the fact that you can’t directly use XAML in a Visual C++ project doesn’t mean that WPF applications can’t be written with Visual C++.

Three ways to write WPF apps using VC++

You can use three different approaches to write WPF applications using Visual C++. Each has its pros and cons, and we’ll cover each of these approaches in the next section:

• Use procedural code.

For one thing, you can directly use procedural code to

write Avalon-based applications and avoid using XAML. Of course, if you

do that, you automatically give up the advantages of declarative programming

that XAML brings in, but for certain scenarios, procedural code often

serves the purpose well.

• Dynamically load XAML.

Alternatively, you can dynamically load XAML during runtime to create your Avalon windows, although the disadvantage is that you’d be distributing a bunch of XAML files with your application.

• Derive from a class in a C# DLL

A third technique uses a C# project to create your XAML-based Avalon controls and have a class (or classes) in your C++ project that derives from the classes in the C#-based Avalon DLL. With that mechanism, the UI is created using XAML in the C# project, and the business logic is kept in the C++ project.

When you’re developing WPF applications with C++, you can use one or more of these approaches to achieve whatever functionality you want. In the next section, you’ll see how to write a simple WPF app with C++/CLI using each of the three techniques mentioned here.

7.2 Using C++/CLI to write a WPF application

If Visual C++ doesn’t have support for XAML, and there are no project templates for building an Avalon application (as of the June 2006 CTP), how much extra effort does it take to write Avalon applications using C++? In this section, you’ll find out. You’ll put the three different techniques I described at the end of section

7.1.2 into action. All three mechanisms have their advantages and disadvantages; you can decide which is most suitable for your specific scenario. First, though, let’s briefly go over how to create a new C++/CLI project for Avalon.

7.2.1 Creating a new C++/CLI Avalon project

Avalon is a managed framework, and as such any Visual C++ project that needs to access and use Avalon needs to have the /clr compilation mode turned on.

Creating a new C++/CLI project with support for Avalon is fortunately not a difficult task. Table 7.1 lists the few simple steps you need to follow each time you create an application (or library, as the case might be) that uses Avalon.

Table 7.1 Steps to create a C++/CLI Avalon project

Step Action	How To
1 Generate a new project	Using the application wizard, specify the CLR Empty Project template.
2 Set the SubSystem to /SUBSYSTEM:WINDOWS	Apply this change in the Project properties, Linker settings, System sub-setting.
3 Set the Entry Point to main	From Project properties, choose Linker settings and then the Advanced sub-setting.
4 Add references to the following assemblies: System PresentationCore PresentationFramework WindowsBase	Note: Except for System, the other three are required for Avalon.

At this point, your empty project is ready for writing Avalon code. Of course, you don’t have any code yet to compile, but you’ll fix that soon.

7.2.2 Using procedural code

You’ll now write your first Avalon application using C++/CLI, and you’ll do so entirely using procedural code. Think of it as analogous to an instruction book for putting together a table that contains only textual instructions (analogous to the procedural code) and no pictures (analogous to the XAML).

Create a new CLR project using the steps outlined in the previous section, and add an App.cpp file to it (you can call it whatever you want). Listing 7.2 shows the code for the simplest Avalon application that shows a window onscreen.

Listing 7.2 A simple Avalon app in procedural code

If you compile and run the application, you’ll see a window onscreen that can be moved, resized, minimized, maximized, and closed. Avalon requires you to set the COM threading model to single threaded apartment (STA). You do so using the STAThread attribute on the main function ①. You then create a new instance of the Application object (using gcnew) and invoke the Run method on that instance, passing in a new instance of a Window object (again using gcnew) ②. The Application class represents an Avalon application and provides the core functionality for running the application. It has a Run method that is called to initiate the application’s main thread. The Run method has an overload that accepts a Window object, which you use in the code. This overload launches the application and uses the specified Window as the main application window. The Window class represents the core functionality of a window and by default provides you with basic windowing functionality such as moving, resizing, and so on, which you verified when you ran the application and saw a fully functional window onscreen.

Note: Those of you who have an MFC background may see a faint similarity between this model and MFC, where the CWinApp class is analogous to the Application class, and the CFrameWnd class is analogous to the Window

class. CWinApp has a Run method that provides the default message loop, and Application::Run does something similar. Of course, you shouldn’t infer too much from these minor similarities because they’re totally different UI programming models, but it’s possible that a similar design model was used by the architects of Avalon.

This little program doesn’t have a lot of functionality; it just uses the default Window object to create and show a window onscreen. Let’s write a more refined application with its own Application-derived object as well as a window with some controls. Figure 7.4 shows a screenshot of what the enhanced application

will look like.

The main steps involved would be to derive two classes-one from the Window class, and the other from the Application class. You’ll start with the Window-derived class.

Figure 7.4

Enhanced WPF app in C++ (procedural code)

Writing the Window-derived class

The first thing you’ll do is add a new class called FirstWindow to your project, which will be derived from the Window class. You’ll also add some member variables for the various controls and set some of the window properties in the constructor. Listing 7.3 shows the code once you’ve done that.

Listing 7.3 A more functional Avalon app in procedural code

using namespace System;

using namespace System::Windows;

using namespace System::Windows::Controls;

It’s much like Windows Forms programming, except that the controls you declare ①. are from the System::Windows::Controls namespace (which contains various WPF controls). You set properties like Title, Width, Height, and so on on the window object in the constructor ②. There’s also a call to a method called InitControls ③, where you initialize the child controls (I put it into a separate method to improve the code’s readability). Listing 7.4 shows the InitControls method. Basically, you instantiate each of the child controls, instantiate a container control, add the child controls to the container controls, and finally set the container control as the main Content of the parent window.

Listing 7.4 Function to initialize the Avalon controls

void InitControls(void)

{
      listbox = gcnew ListBox();
      listbox->Width = 180;

      listbox->Height = 350;

      Canvas::SetTop(listbox, 10);

      Canvas::SetLeft(listbox, 10);

      textbox = gcnew TextBox();

      textbox->Width = 180;

      textbox->Height = 25;
    
      Canvas::SetTop(textbox, 10);

      Canvas::SetLeft(textbox, 200);

      addbutton = gcnew Button();

      addbutton->Width = 80;

      addbutton->Height = 25;

      addbutton->Content = "Add";

      Canvas::SetTop(addbutton, 45);

      Canvas::SetLeft(addbutton, 200);

      addbutton->Click += gcnew RoutedEventHandler(this, &FirstWindow::OnAddButtonClick);

      maincanvas = gcnew Canvas();

      maincanvas->Children->Add(listbox);

      maincanvas->Children->Add(textbox);

      maincanvas->Children->Add(addbutton);

      Content = maincanvas;
}

Again, you probably notice the similarity with Windows Forms programming.

You instantiate the child controls ①, ②, and ③, and set various properties like Width and Height, and you also use the Canvas::SetTop and Canvas::SetLeft methods to position them on their container. For the button control, you also add an event handler for the Click event ④. Then, you instantiate the Canvas control (which is a container control for other child controls) and add the child controls as its children ⑤. Finally, you set the Content property of the window to this Canvas control ⑥.

Now, you need to add the Click event handler for the button control, where you add the text entered into the TextBox to the ListBox:

void OnAddButtonClick(Object^ sender, RoutedEventArgs^ e)
{
​	listbox->Items->Add(textbox->Text);
​	textbox->Text = "";
​	textbox->Focus();
}

Notice that you set the text of the TextBox to an empty string once you’ve added it to the ListBox. You also call the Focus() method so that the user can continue

adding more entries into the ListBox. The Window-derived class is ready. Let’s now write the Application-derived class.

Writing the Application-derived class

You derive a class called FirstApp from Application and add an override for the OnStartup method where you create and show the main window:

#include "FirstWindow.h"

ref class FirstApp : Application
{
public:
FirstApp(void){}

protected:
      virtual void OnStartup(StartupEventArgs^ e) override
      {
          Application::OnStartup(e);
          FirstWindow^ mainwnd = gcnew FirstWindow();
          mainwnd->Show();
      }
};

The OnStartup method is called, not surprisingly, when the application has just started. You override that function so that you can instantiate and show the window.

The base function is responsible for invoking any event handlers associated with the Startup event, and thus you need to call the base method in the override.

Now, all that’s left is to modify the main function to use the custom Application object instead of the default, as shown here:

#include "FirstApp.h"

[STAThread]

int main(array<String^>^ args)
{
	return (gcnew FirstApp())->Run();
}

Notice that you don’t specify a window object to the Run method, because the window object is created in the OnStartup override of your Application-derived class.

Compile and run the application, and try entering some text into the TextBox and clicking the Add button. You should see the text being entered into the ListBox.

When you use procedural code with Avalon, it’s much like using Windows Forms, where you derive classes from the default controls, set some properties, add some event handlers, and are done. Procedural code is all right to develop WPF applications for simple user interfaces, but sometimes it makes better sense

to take advantage of XAML and declarative programming. As I’ve mentioned a few times already, XAML isn’t directly supported in VC++, so you’ll have to look at alternate options to make use of XAML. One such option is to dynamically load the XAML at runtime.

7.2.3 Dynamically loading XAML

In this section, you’ll rewrite the application you wrote in the previous section, using dynamically loaded XAML. This way, you get to leverage the power of XAML and declarative programming (which you couldn’t in the procedural code technique you used in the previous section). Continuing the instruction-book analogy, this will be like one that has textual instructions that refer to pictures (which describe the various steps needed) and are loosely distributed along with the book but not directly printed in the book. You’ll define the UI using XAML instead of procedural code. When you’re done, you’ll have an identical application

to the one you previously created.

Create a new C++/CLI Avalon project using the steps mentioned in the introduction to section 7.2, and call it FirstAvalonDynamic (or whatever you want to call it). The first thing you’ll do is write the XAML (MainWindow.xaml) that represents the UI; see listing 7.5.

Listing 7.5 XAML for the main window

<Window

     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

     Title="First Avalon App (dynamically load XAML)"

     Height="400" Width="400"

     ResizeMode="NoResize"

     > 

     <Canvas>
           <ListBox Canvas.Left="10" Canvas.Top="10"
                 Width="180" Height="350"
                 Name="listbox" />
               <TextBox Canvas.Left="200" Canvas.Top="10"
                 Width="180" Height="25"
                 Name="textbox" />
           <Button Canvas.Left="200" Canvas.Top="45"
                 Width="80" Height="25"
                 Name="addbutton">Add</Button>
     </Canvas>
</Window>

The XAML shown does exactly what you did with the procedural code earlier. For the control elements, you use the same names using the Name attribute as you use for the member variables in the procedural code. Next, you need to hook an event handler to the Button so that the text entered into the TextBox is inserted

into the ListBox. For that, you’ll write a helper class, as shown in listing 7.6.

Listing 7.6 WindowHelper class that implements the event handler

using namespace System;

using namespace System::Windows;

using namespace System::Windows::Controls;

using namespace System::Windows::Markup;

using namespace System::IO;

ref class WindowHelper
{

     ListBox^ listbox;

     TextBox^ textbox;

     Button^ addbutton;



public:
WindowHelper(Window^ window)
{
   addbutton = (Button^)window->FindName("addbutton");

   textbox = (TextBox^)window->FindName("textbox");

   listbox = (ListBox^)window->FindName("listbox");

   addbutton->Click += gcnew RoutedEventHandler(

   this,&WindowHelper::OnAddButtonClick);
}

void OnAddButtonClick(Object^ sender, RoutedEventArgs^ e)
{
   listbox->Items->Add(textbox->Text);

   textbox->Text = "";

   textbox->Focus();
}

};

The WindowHelper constructor accepts a Window argument and uses the FindName method ① to get the control with the specified identifier (which maps to the Name attributes you used in the XAML). You also hook an event handler to the addbutton control ②. Finally, you have the event handler③, which is identical to the one you used in the procedural code project. Listing 7.7 shows the code for the Application-derived class, where you override OnStartup as before, except that you create a window dynamically by loading the XAML file from the disk.

Listing 7.7 The Application-derived class

ref class FirstAppDynamic : Application

{

public:

     FirstAppDynamic(void)
     {

     }

protected:
     virtual void OnStartup(StartupEventArgs^ e) override
     {

           Application::OnStartup(e);

           Stream^ st = File::OpenRead("MainWindow.xaml");

           Window^ mainwnd = (Window^)XamlReader::Load(st);

           st->Close();

           WindowHelper^ mainwndhelper = gcnew WindowHelper(mainwnd);

           mainwnd->Show();

     }

};

You open a file stream to the XAML using File::OpenRead ① and use the overload of XamlReader::Load ② that takes a Stream^ as parameter to create a Window object. This Load method works the magic, by reading and parsing the XAML and building a Window object out of it. You instantiate the WindowHelper object and pass

this Window object as the argument, so that the event handler for the addbutton control is properly set up ③. You then show the window ④ with a call to Show().

The main method is much the same as before, where you instantiate the Application object and call Run on it:

[STAThread]
int main(array<String^>^ args)
{

      return (gcnew FirstAppDynamic())->Run();

}

The advantage of using this technique over using procedural code is that you get to design your UI in XAML, thereby achieving a level of UI/code separation. You can also use Cider or some other XAML designer to quickly design flexible user interfaces, which would involve a good bit of hand-coding in procedural code.

The disadvantage is that you have to distribute the XAML file with your application, and if you have multiple windows, you then need that many XAML files.

There’s always the risk of a loosely-distributed XAML file getting corrupted (accidentally or otherwise) or even being deleted. You can embed all the XAML files as resources in the C++/CLI assembly and load them at runtime, but even that involves a lot of extra work. To avoid distributing XAML files loosely with your

application or embedding them as resources, you may want to use the technique we’ll discuss in the next section: putting the XAML into a C# project and accessing it via a derived class in a C++ project.

7.2.4 Deriving from a class in a C# DLL

You’ll write a third variation of the same application in this section. You’ll use a C# control library project for the XAML, and a C++ project that will utilize that XAML control by deriving a control from it. Using the instruction-book analogy again, this is essentially a picture-based, step-by-step guide with the textual

instructions printed alongside each picture providing some meta-information for the step indicated by that picture. First, use the New Project Wizard to generate a new C# .NET 3.0 Custom Control Library project, and delete the default XAML file generated by the wizard. The default XAML is derived from User-

Control and isn’t what you want. Add a new XAML file to the C# project that represents a Window, and either use Cider or hand-code the XAML from listing 7.8 into that file.

Listing 7.8 The Window class definition using XAML

<Window x:Class="CSXamlLibrary.BaseWindow"
     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
     Title="First Avalon App (dynamically load XAML)"
     Height="400" Width="400"
     ResizeMode="NoResize"
     > 

     <Canvas>
           <ListBox Canvas.Left="10" Canvas.Top="10"
                 Width="180" Height="350"
                 Name="listbox" x:FieldModifier="protected" />

           <TextBox Canvas.Left="200" Canvas.Top="10"
                 Width="180" Height="25"
                 Name="textbox" x:FieldModifier="protected" />

           <Button Canvas.Left="200" Canvas.Top="45"
                 Width="80" Height="25"
                 Name="addbutton" x:FieldModifier="protected">Add</Button>
     </Canvas>

</Window>

The XAML is identical to that used in the previous project (where you dynamically loaded it) except for the x:Class attribute for the Window element, which specifies the name of the class that will be generated, and the x:FieldModifier attributes that are applied to the child control elements so they’re generated as protected members in the class (rather than as private which is the default). Build the C# project, and generate the control library. Once that’s done, create a new C++/CLI Avalon project (using the same steps as before), and then add a reference to this C# project. Now, you can write a new Window class that’s derived from the class in the C# DLL, as shown in listing 7.9.

Listing 7.9 Deriving the main window from the XAML-defined Window class

using namespace System;

using namespace System::Windows;

using namespace System::Windows::Controls;



ref class AppMainWindow : CSXamlLibrary::BaseWindow
{
     public:
           AppMainWindow(void)
           {
                 addbutton->Click += gcnew RoutedEventHandler(this, &AppMainWindow::OnAddButtonClick);
           }

           void OnAddButtonClick(Object^ sender, RoutedEventArgs^ e)
           {

                 listbox->Items->Add(textbox->Text);

                 textbox->Text = "";

                 textbox->Focus();

           }

};

The code is similar to what you’ve seen thus far, except that it’s a lot cleaner.

Unlike the first example, you don’t have a lot of clogged procedural code to create the UI. Unlike the second example, you don’t need a helper class to map the XAML elements to the control variables and event handlers. It’s definitely an improvement over the previous two examples, but you have to bring in the C#

project just for the XAML. The rest of the code needed for the application is more or less similar to what you saw earlier:

ref class FirstAppDerived : Application
{
      protected:
            virtual void OnStartup(StartupEventArgs^ e) override
            {
                  Application::OnStartup(e);
                  AppMainWindow^ mainwnd = gcnew AppMainWindow();
                  mainwnd->Show();
            }

};

[STAThread]

int main(array<String^>^ args)
{
      return (gcnew FirstAppDerived())->Run();
}

In some ways, the third technique is a sort of hybrid of the previous two techniques.

A lot of the code is identical to that in the first technique – as with the declaration of a custom class derived from Window and an Application-derived class with the OnStartup method creating the custom window. But, like the second technique, the UI definition is in the XAML, except that in this case, it’s compiled into the C# DLL. You also reduce lines of code with each successive technique. You had the most lines of code with procedural code (as is to be expected) and improved on that considerably when you moved the UI definition to the XAML in the dynamically-loaded XAML example. In the last example, you saved even further on lines of code, such as the helper class from the second example that had to wire the XAML elements to the member variables. Of course, the total lines of code (LOC) isn’t always the single deciding factor that determines what technique you choose. Table 7.2 shows a comparison of the three techniques; for each factor, the cells with the bold text reflect the technique (or techniques) that offer maximum performance (or convenience).

Table 7.2 Comparison of the three techniques

	Procedural code	Dynamically load XAML	XAML in C# DLL
Cluttered code that generates the UI	Yes	No	No
Dependency on loose XAML files	No	Yes	No
Dependency on C#-based DLL	No	No	Yes
Lines of code	Maximum	In-between	Minimum
UI design convenience	Poor	Excellent	Excellent
UI/business logic separation	Poor	Good	Excellent
Level of Visual C++ project support	Total	Partial	(Not applicable)

It’s hard to pinpoint a specific technique and claim that it’s the best one, because depending on your requirements, each has advantages and disadvantages. Of course, in the future, if Visual C++ has direct support for XAML (as I believe it will), that will be your best option for the majority of scenarios.

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

ABP框架簡述

1）簡介

在.NET眾多的技術框架中，ABP框架（本系列中指aspnetboilerplate項目）以其獨特的魅力吸引了一群優秀開發者廣泛的使用。

在該框架的賦能之下，開發者可根據需求通過官方網站【https://aspnetboilerplate.com/Templates】選擇下載例如Vue/AngluarJS/MVC等不同類型的模板項目，輕鬆加入ABP開發者的隊伍中，盡享基於ABP開發帶來的樂趣。

ABP開發框架也提供了豐富的文檔，能夠為開發者帶來許多便捷。目前ABP的文檔網站為：

官方文檔：https://aspnetboilerplate.com/Pages/Documents

文檔庫不可謂不全，加上國內眾多的ABP開發者參与的活躍的技術圈子，使得學習成本只是在第一個項目中比較高，後期將會越來越平滑。

2）現狀

當然，目前ABP的框架開發者和社區已經把更多的精力投入到了ABP.VNEXT開發框架，這個新框架以其DDD+微服務+模塊化的理念獲得了大量擁躉，使ABP框架的開發優先級已經開始逐漸降低。

但這是因為ABP框架的功能已經成熟穩定，且ABP是一種增量式的架構設計，開發者在熟練掌握這種框架后，可以根據自己的需要進行方便的擴展，使其成為小項目架構選型中一種不錯的備選方案。

當然，也存在一些弊端。例如由於ABP被稱為.NET眾多開發框架中面向領域驅動設計的最佳實踐，而囿於領域驅動設計本身不低的門檻，使得學習的過程變得看起來非常陡峭；

除此之外，ABP也廣泛使用了目前Asp.NET/Asp.NET Core框架的大量比較新的特性，對於不少無法由於各種原因無法享受.NET技術飛速發展紅利的傳統開發者來說，無形中也提高了技術門檻。

3）綜述

在這個系列中，本文計劃分成三篇來介紹ABP框架，第一篇介紹ABP的基礎概覽，介紹基礎知識，第二篇介紹ABP的模式實踐，第三篇，試圖介紹如何從更傳統的三層甚至是單層+SQL的單層架構，如何遷移到ABP框架。

（畢竟。。.NET遺留應用實在是太多了，拯救或不拯救？）

代碼結構結構

基本文件夾簡述

當我們通過ABP模板項目的官方網站下載一個項目后，我們所獲得的代碼包的結構如下圖所示，其中：

• vue為使用iview框架構建的管理系統基本模板，該腳手架使用了yarn作為包管理器，並集成了vuex/axios等常用框架，並提供了用戶，租戶，權限三個基本功能的示例代碼，開發者只需發揮聰明才智就能快速的通過該框架入手前端項目。
• （當然，該項目廣泛使用了typescript+面向對象的設計，似乎前端開發者。。普遍不擅長面向對象開發？）
• aspnet-core則是一個完整的asp.netcore項目的快速開發腳手架。該腳手架集成了docker打包於一體，並包含基本的單元測試示例，使用了identity作為權限控制單元，使用swagger作為接口文檔管理工具，集成了efcore、jwt等常用組件，對於開發者來說，基本上算是開箱即用了。

前端vue項目

打開vue文件夾之後，該項目的基本目錄如下圖所示。（src文件夾）

lib文件夾

定義了與abp+vue腳手架項目的基礎組件和常見類庫，封裝了一系列基本方法。例如權限控制，數據請求，菜單操作，SignalR等基礎組件的用法。

router文件夾

定義了vue項目的路由規則，其中index.ts文件是項目的入口，router.ts文件定義了vue文件的路由規則。

store文件夾

由於本項目使用了vuex框架，所以我們可以來看看對於store文件夾的介紹。

在vuex框架中：

每一個 Vuex 應用的核心就是 store（倉庫）。“store”基本上就是一個容器，它包含着你的應用中大部分的狀態 (state)。
Vuex 和單純的全局對象有以下兩點不同：
Vuex 的狀態存儲是響應式的。當 Vue 組件從 store 中讀取狀態的時候，若 store 中的狀態發生變化，那麼相應的組件也會相應地得到高效更新。
你不能直接改變 store 中的狀態。改變 store 中的狀態的唯一途徑就是顯式地提交 (commit) mutation。這樣使得我們可以方便地跟蹤每一個狀態的變化，從而讓我們能夠實現一些工具幫助我們更好地了解我們的應用。

即vuex框架中，將原來的請求鏈路，抽象化為狀態的變化，通過維護狀態，使得數據的管理更加便捷，也易於擴展。

views文件夾

定義了登錄、首頁、用戶、角色、租戶的基本頁面，並提供了新增、查看、編輯、刪除的代碼示例。

綜上，該項目是一個結構清晰，邏輯縝密的前端框架，可以作為常見管理系統的腳手架。

後端項目

簡介

後端項目是一個遵循了領域驅動設計的分層，同時又符合Robert Martin在《代碼整潔之道》提出的【整潔架構】。

領域驅動設計簡介

在領域驅動設計的分層設計中，共有四個功能分層，分別是：

表示層（Presentation Layer）：為用戶提供接口，使用應用層實現用戶交互。

應用層（Application Layer）：介於用戶層和領域層之間，協調用戶對象，完成對應的任務。

領域層（Domain Layer）：包含業務對象和規則，是應用程序的心臟。

基礎設施層（Infrastructure Layer）：提供高層級的通用技術功能，主要使用第三方庫完成。

在後文中，基於abp對領域驅動設計的功能分層將進行多次、詳細敘述，本小節不再贅述。

整潔架構簡介

整潔架構是由Bob大叔提出的一種架構模型，來源於《整潔架構》這本書，顧名思義，其目的並不是為了介紹這一種優秀的架構本身，而是介紹如何設計一種整潔的架構，使得代碼結構易於維護。

（整潔架構就是這樣一個洋蔥，所以也有人稱它為“洋蔥”架構）

1. 依賴規則(Dependency Rule)

用一組同心圓來表示軟件的不同領域。一般來說，越深入代表你的軟件層次越高。外圓是戰術是實現機制(mechanisms)，內圓的是核心原則(policy)。

Policy means the application logic.

Mechanism means the domain primitives.

使此體系架構能夠工作的關鍵是依賴規則。這條規則規定軟件模塊只能向內依賴，而裏面的部分對外面的模塊一無所知，也就是內部不依賴外部，而外部依賴內部。同樣，在外面圈中使用的數據格式不應被內圈中使用，特別是如果這些數據格式是由外面一圈的框架生成的。我們不希望任何外圓的東西會影響內圈層

1. 實體 (Entities)

實體封裝的是整個企業範圍內的業務核心原則(policy)，一個實體能是一個帶有方法的對象，或者是一系列數據結構和函數，只要這個實體能夠被不同的應用程序使用即可。

如果你沒有編寫企業軟件，只是編寫簡單的應用程序，這些實體就是應用的業務對象，它們封裝着最普通的高級別業務規則，你不能希望這些實體對象被一個頁面的分頁導航功能改變，也不能被安全機制改變，操作實現層面的任何改變不能影響實體層，只有業務需求改變了才可以改變實體

1. 用例 (Use case)

在這個層的軟件包含只和應用相關的業務規則，它封裝和實現系統的所有用例，這些用例會混合各種來自實體的各種數據流程，並且指導這些實體使用企業規則來完成用例的功能目標。

我們並不期望改變這層會影響實體層. 我們也不期望這層被更外部如數據庫 UI或普通框架影響，而這也正是我們分離出這一層來的原因所在。

然而，應用層面的操作改變將會影響到這個用例層，如果需求中用例發生改變，這個層的代碼就會隨之發生改變。所以可以看到，這一層是和應用本身緊密相關的

1. 接口適配器 (Interface Adapters)

這一層的軟件基本都是一些適配器，主要用於將用例和實體中的數據轉換為外部系統如數據庫或Web使用的數據，在這個層次，可以包含一些GUI的MVC架構，表現視圖 控制器都屬於這個層，模型Model是從控制器傳遞到用例或從用例傳遞到視圖的數據結構。

通常在這個層數據被轉換，從用例和實體使用的數據格式轉換到持久層框架使用的數據，主要是為了存儲到數據庫中，這個圈層的代碼是一點和數據庫沒有任何關係，如果數據庫是一個SQL數據庫， 這個層限制使用SQL語句以及任何和數據庫打交道的事情。

1. 框架和驅動器

最外面一圈通常是由一些框架和工具組成，如數據庫Database, Web框架等. 通常你不必在這個層不必寫太多代碼，而是寫些膠水性質的代碼與內層進行粘結通訊。

這個層是細節所在，Web技術是細節，數據庫是細節，我們將這些實現細節放在外面以免它們對我們的業務規則造成影響傷害

ABP的分層實現

在ABP項目中，層次劃分如下。

1. 應用層（Application項目）

在領域驅動設計的分層式架構中，應用層作為應用系統的北向網關，對外提供業務外觀的功能。在Abp模板項目中,Application項目也是編寫主要用例代碼的位置，開發者們在此定義與界面有關的數據行為，實現面向接口的開發實踐。

應用服務層包含應用服務，數據傳輸單元，工作單元等對象。

• Application Service

為面向用戶界面層實現業務邏輯代碼。例如需要為某些界面對象組裝模型，通常會定義ApplicationService，並通過DTO對象，實現與界面表現層的數據交換。

• Data Transfer Object (DTO)

最常見的數據結構為DTO（數據傳輸對象），這是來源於馬丁弗勒在《企業架構應用模式》中提到的名詞，其主要作用為：

是一種設計模式之間傳輸數據的軟件應用系統。 數據傳輸目標往往是數據訪問對象從數據庫中檢索數據。

在ABP的設計中，有兩種不同類型的DTO，分別是用於新增、修改、刪除的Input DTO，和用於查詢的Output DTO。

• Unit of Work：

工作單元。工作單元與事務類似，封裝了一系列原子級的數據庫操作。

2. 核心層（Core項目）

核心層包含領域實體、值對象、聚合根，以及領域上下文實現。

• Entity(實體）：

實體有別於傳統意義上大家所理解的與數據庫字段一一匹配的實體模型，在領域驅動設計中,雖然實體同樣可能持久化到數據庫，但實體包含屬性和行為兩種不同的抽象。

例如，如果有一個實體為User，其中有一個屬性為Phone，數據為086-132xxxxxxxx，我們有時需要判斷該手機號碼的國際代號，可能會添加一個新的判定 GetNationCode()，可以通過從Phone字段中取出086來實現，這就是一種通俗意義上的行為。

• Value Object（值對象）:

值對象無需持久化到數據庫，往往是從其他實體或聚合中“剝離”出來的與某些聚合具備邏輯相關性或語義相關性的對象，有時值對象甚至只有個別屬性。

例如，上述實體，包含Phone字段，我們可以將整個Phone“剝離”為一個Telephone對象，該對象可包含PhoneNumber和NationCode字段。

public class User
{
     public Telephone Phone{public get;private set;}
}
public class Telephone
{
    public string  PhoneNumber {get;set;}
     public string NationCode  {get;set;}
}

• Aggregate & Aggregate Root（聚合，聚合根）：

聚合是業務的最小工作單元，有時，一個實體就是一個小聚合，而為聚合對外提供訪問機制的對象，就是聚合根。

在領域驅動設計中，識別聚合也是一件非常重要的工作，有一組系統的方法論可以為我們提供參考。

當然，事實上識別領域對象，包括且不限定於識別聚合、值對象、實體識別該對象的行為或（方法）本身是一件需要經驗完成的工作，有時需要UML建模方法的廣泛參与。

有時，我們會習慣於通過屬性賦值完成梭代碼的過程，從而造成領域行為流失在業務邏輯層的問題，那麼或許可以採取這樣的方法：

1、對象的創建，使用構造函數賦值，或工廠方法創建。

2、將所有對於屬性的訪問級別都設置為

public string Phone{public get;private set;}

然後再通過一個綁定手機號碼的方法，來給這個對象設置手機號碼。

public string BindPhone(string phone)
{
}

將所有一切涉及到對Phone的操作，都只能通過規定的方法來賦值，這樣可以實現我們開發過程中，無意識的通過屬性賦值，可能導致的“領域行為”丟失的現象發生。
這種方式可以使得對對象某些屬性的操作，只能通過唯一的入口完成，符合單一職責原則的合理運用，如果要擴展方法，可以使用開閉原則來解決。

但是，採用這種方式，得盡量避免出現：SetPhone(string phone) 這樣的方法出現，畢竟這樣的方法，其實和直接的屬性賦值，沒有任何區別。

• Repository（倉儲）

倉儲封裝了一系列對象數據庫操作的方法，完成對象從數據庫到對象的轉換過程。在領域驅動設計中，一個倉儲往往會負責一個聚合對象從數據庫到創建的全過程。

• Domain Service（領域服務）

領域服務就是“實幹家”，那些不適合在領域對象中出現，又不屬於對象數據庫操作的方法，又與領域對象息息相關的方法，都可以放到領域服務中實現。

• Specification（規格定義）

規範模式是一種特殊的軟件設計模式，通過使用布爾邏輯將業務規則鏈接在一起，可以重新組合業務規則。

實際上，它主要用於為實體或其他業務對象定義可重用的過濾器。

3. 其他基礎設施（EntityFrameworkCore，Web.Core,Web.Host項目)

EntityFrameworkCore負責定義數據庫上下文和對EFCore操作的一系列規則、例如種子數據的初始化等。

Web.Core：定義了應用程序的外觀和接口。雖然從表面上看，Web.Core定義了作為Web訪問入口的控制器方法和登錄驗證的邏輯，看起來像是用戶表現層的東西，但是仔細想想，這些東西，何嘗不是一種基礎設施？

Web.Host：定義WEB應用程序的入口。

總結

本文簡述了ABP框架的前後端項目的分層結構，通過了解這些結構，將有助於我們在後續的實戰中更快入手，為應用開發插上翅膀。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

※新北清潔公司,居家、辦公、裝潢細清專業服務