跳到主要內容

MongoDB via Dotnet Core數據映射詳解


用好數據映射，MongoDB via Dotnet Core開發變會成一件超級快樂的事。



 


一、前言


MongoDB這幾年已經成為NoSQL的頭部數據庫。


由於MongoDB free schema的特性，使得它在互聯網應用方面優於常規數據庫，成為了相當一部分大廠的主數據選擇；而它的快速布署和開發簡單的特點，也吸引着大量小開發團隊的支持。


關於MongoDB快速布署，我在15分鐘從零開始搭建支持10w+用戶的生產環境(二)里有寫，需要了可以去看看。


 


作為一個數據庫，基本的操作就是CRUD。MongoDB的CRUD，不使用SQL來寫，而是提供了更簡單的方式。


方式一、BsonDocument方式


BsonDocument方式，適合能熟練使用MongoDB Shell的開發者。MongoDB Driver提供了完全覆蓋Shell命令的各種方式，來處理用戶的CRUD操作。


這種方法自由度很高，可以在不需要知道完整數據集結構的情況下，完成數據庫的CRUD操作。


方式二、數據映射方式


數據映射是最常用的一種方式。準備好需要處理的數據類，直接把數據類映射到MongoDB，並對數據集進行CRUD操作。


 


下面，對數據映射的各個部分，我會逐個說明。


    為了防止不提供原網址的轉載，特在這裏加上原文鏈接：https://www.cnblogs.com/tiger-wang/p/13185605.html


二、開發環境&基礎工程


這個Demo的開發環境是：Mac + VS Code + Dotnet Core 3.1.2。


建立工程：


% dotnet new sln -o demo
The template "Solution File" was created successfully.
% cd demo 
% dotnet new console -o demo
The template "Console Application" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on demo/demo.csproj...
  Determining projects to restore...
  Restored demo/demo/demo.csproj (in 162 ms).

Restore succeeded.
% dotnet sln add demo/demo.csproj 
Project `demo/demo.csproj` added to the solution.

建立工程完成。


下面，增加包mongodb.driver到工程：


% cd demo
% dotnet add package mongodb.driver
  Determining projects to restore...
info : Adding PackageReference for package 'mongodb.driver' into project 'demo/demo/demo.csproj'.
info : Committing restore...
info : Writing assets file to disk. Path: demo/demo/obj/project.assets.json
log  : Restored /demo/demo/demo.csproj (in 6.01 sec).

項目準備完成。


看一下目錄結構：


% tree .
.
├── demo
│   ├── Program.cs
│   ├── demo.csproj
│   └── obj
│       ├── demo.csproj.nuget.dgspec.json
│       ├── demo.csproj.nuget.g.props
│       ├── demo.csproj.nuget.g.targets
│       ├── project.assets.json
│       └── project.nuget.cache
└── demo.sln

 


mongodb.driver是MongoDB官方的數據庫SDK，從Nuget上安裝即可。


三、Demo準備工作


創建數據映射的模型類CollectionModel.cs，現在是個空類，後面所有的數據映射相關內容會在這個類進行說明：


public class CollectionModel
{
}

並修改Program.cs，準備Demo方法，以及連接數據庫:


class Program
{
    private const string MongoDBConnection = "mongodb://localhost:27031/admin";

    private static IMongoClient _client = new MongoClient(MongoDBConnection);
    private static IMongoDatabase _database = _client.GetDatabase("Test");
    private static IMongoCollection<CollectionModel> _collection = _database.GetCollection<CollectionModel>("TestCollection");

    static async Task Main(string[] args)
    {
        await Demo();
        Console.ReadKey();
    }

    private static async Task Demo()
    {
    }
}

四、字段映射


從上面的代碼中，我們看到，在生成Collection對象時，用到了CollectionModel：


IMongoDatabase _database = _client.GetDatabase("Test");
IMongoCollection<CollectionModel> _collection = _database.GetCollection<CollectionModel>("TestCollection");

這兩行，其實就完成了一個映射的工作：把MongoDB中，Test數據庫下，TestCollection數據集（就是SQL中的數據表），映射到CollectionModel這個數據類中。換句話說，就是用CollectionModel這個類，來完成對數據集TestCollection的所有操作。


 


保持CollectionModel為空，我們往數據庫寫入一行數據：


private static async Task Demo()
{
    CollectionModel new_item = new CollectionModel();
    await _collection.InsertOneAsync(new_item);
}

執行，看一下寫入的數據：


{ 
    "_id" : ObjectId("5ef1d8325327fd4340425ac9")
}

OK，我們已經寫進去一條數據了。因為映射類是空的，所以寫入的數據，也只有_id一行內容。


 


但是，為什麼會有一個_id呢？


1. ID字段


MongoDB數據集中存放的數據，稱之為文檔（Document）。每個文檔在存放時，都需要有一個ID，而這個ID的名稱，固定叫_id。


當我們建立映射時，如果給出_id字段，則MongoDB會採用這個ID做為這個文檔的ID，如果不給出，MongoDB會自動添加一個_id字段。


例如：


public class CollectionModel
{
    public ObjectId _id { get; set; }
    public string title { get; set; }
    public string content { get; set; }
}

和


public class CollectionModel
{
    public string title { get; set; }
    public string content { get; set; }
}

在使用上是完全一樣的。唯一的區別是，如果映射類中不寫_id，則MongoDB自動添加_id時，會用ObjectId作為這個字段的數據類型。


ObjectId是一個全局唯一的數據。


當然，MongoDB允許使用其它類型的數據作為ID，例如：string，int，long，GUID等，但這就需要你自己去保證這些數據不超限並且唯一。


例如，我們可以寫成：


public class CollectionModel
{
    public long _id { get; set; }
    public string title { get; set; }
    public string content { get; set; }
}

 


我們也可以在類中修改_id名稱為別的內容，但需要加一個描述屬性BsonId：


public class CollectionModel
{
    [BsonId]
    public ObjectId topic_id { get; set; }
    public string title { get; set; }
    public string content { get; set; }
}

這兒特別要注意：BsonId屬性會告訴映射，topic_id就是這個文檔數據的ID。MongoDB在保存時，會將這個topic_id轉成_id保存到數據集中。


在MongoDB數據集中，ID字段的名稱固定叫_id。為了代碼的閱讀方便，可以在類中改為別的名稱，但這不會影響MongoDB中存放的ID名稱。


 


修改Demo代碼：


private static async Task Demo()
{
    CollectionModel new_item = new CollectionModel()
    {
        title = "Demo",
        content = "Demo content",
    };
    await _collection.InsertOneAsync(new_item);
}

跑一下Demo，看看保存的結果：


{ 
    "_id" : ObjectId("5ef1e1b1bc1e18086afe3183"), 
    "title" : "Demo", 
    "content" : "Demo content"
}

2. 簡單字段


就是常規的數據字段，直接寫就成。


public class CollectionModel
{
    [BsonId]
    public ObjectId topic_id { get; set; }
    public string title { get; set; }
    public string content { get; set; }
    public int favor { get; set; }
}

保存后的數據：


{ 
    "_id" : ObjectId("5ef1e9caa9d16208de2962bb"), 
    "title" : "Demo", 
    "content" : "Demo content", 
    "favor" : NumberInt(100)
}

3. 一個的特殊的類型 - Decimal


說Decimal特殊，是因為MongoDB在早期，是不支持Decimal的。直到MongoDB v3.4開始，數據庫才正式支持Decimal。


所以，如果使用的是v3.4以後的版本，可以直接使用，而如果是以前的版本，需要用以下的方式：


[BsonRepresentation(BsonType.Double, AllowTruncation = true)]
public decimal price { get; set; }

其實就是把Decimal通過映射，轉為Double存儲。


4. 類字段


把類作為一個數據集的一個字段。這是MongoDB作為文檔NoSQL數據庫的特色。這樣可以很方便的把相關的數據組織到一條記錄中，方便展示時的查詢。


我們在項目中添加兩個類Contact和Author：


public class Contact
{
    public string mobile { get; set; }
}

public class Author
{
    public string name { get; set; }
    public List<Contact> contacts { get; set; }
}

然後，把Author加到CollectionModel中：


public class CollectionModel
{
    [BsonId]
    public ObjectId topic_id { get; set; }
    public string title { get; set; }
    public string content { get; set; }
    public int favor { get; set; }
    public Author author { get; set; }
}

嗯，開始變得有點複雜了。


完善Demo代碼：


private static async Task Demo()
{
    CollectionModel new_item = new CollectionModel()
    {
        title = "Demo",
        content = "Demo content",
        favor = 100,
        author = new Author
        {
            name = "WangPlus",
            contacts = new List<Contact>(),
        }
    };

    Contact contact_item1 = new Contact()
    {
        mobile = "13800000000",
    };
    Contact contact_item2 = new Contact()
    {
        mobile = "13811111111",
    };
    new_item.author.contacts.Add(contact_item1);
    new_item.author.contacts.Add(contact_item2);

    await _collection.InsertOneAsync(new_item);
}

保存的數據是這樣的：


{ 
    "_id" : ObjectId("5ef1e635ce129908a22dfb5e"), 
    "title" : "Demo", 
    "content" : "Demo content", 
    "favor" : NumberInt(100),
    "author" : {
        "name" : "WangPlus", 
        "contacts" : [
            {
                "mobile" : "13800000000"
            }, 
            {
                "mobile" : "13811111111"
            }
        ]
    }
}

這樣的數據結構，用着不要太爽！


5. 枚舉字段


枚舉字段在使用時，跟類字段相似。


創建一個枚舉TagEnumeration：


public enum TagEnumeration
{
    CSharp = 1,
    Python = 2,
}

加到CollectionModel中：


public class CollectionModel
{
    [BsonId]
    public ObjectId topic_id { get; set; }
    public string title { get; set; }
    public string content { get; set; }
    public int favor { get; set; }
    public Author author { get; set; }
    public TagEnumeration tag { get; set; }
}

修改Demo代碼：


private static async Task Demo()
{
    CollectionModel new_item = new CollectionModel()
    {
        title = "Demo",
        content = "Demo content",
        favor = 100,
        author = new Author
        {
            name = "WangPlus",
            contacts = new List<Contact>(),
        },
        tag = TagEnumeration.CSharp,
    };
    /* 後邊代碼略過 */
}

運行后看數據：


{ 
    "_id" : ObjectId("5ef1eb87cbb6b109031fcc31"), 
    "title" : "Demo", 
    "content" : "Demo content", 
    "favor" : NumberInt(100), 
    "author" : {
        "name" : "WangPlus", 
        "contacts" : [
            {
                "mobile" : "13800000000"
            }, 
            {
                "mobile" : "13811111111"
            }
        ]
    }, 
    "tag" : NumberInt(1)
}

在這裏，tag保存了枚舉的值。


我們也可以保存枚舉的字符串。只要在CollectionModel中，tag聲明上加個屬性：


public class CollectionModel
{
    [BsonId]
    public ObjectId topic_id { get; set; }
    public string title { get; set; }
    public string content { get; set; }
    public int favor { get; set; }
    public Author author { get; set; }
    [BsonRepresentation(BsonType.String)]
    public TagEnumeration tag { get; set; }
}

數據會變成：


{ 
    "_id" : ObjectId("5ef1ec448f1d540919d15904"), 
    "title" : "Demo", 
    "content" : "Demo content", 
    "favor" : NumberInt(100), 
    "author" : {
        "name" : "WangPlus", 
        "contacts" : [
            {
                "mobile" : "13800000000"
            }, 
            {
                "mobile" : "13811111111"
            }
        ]
    }, 
    "tag" : "CSharp"
}

6. 日期字段


日期字段會稍微有點坑。


這個坑其實並不源於MongoDB，而是源於C#的DateTime類。我們知道，時間根據時區不同，時間也不同。而DateTime並不準確描述時區的時間。


我們先在CollectionModel中增加一個時間字段：


public class CollectionModel
{
    [BsonId]
    public ObjectId topic_id { get; set; }
    public string title { get; set; }
    public string content { get; set; }
    public int favor { get; set; }
    public Author author { get; set; }
    [BsonRepresentation(BsonType.String)]
    public TagEnumeration tag { get; set; }
    public DateTime post_time { get; set; }
}

修改Demo：


private static async Task Demo()
{
    CollectionModel new_item = new CollectionModel()
    {
        /* 前邊代碼略過 */
        post_time = DateTime.Now, /* 2020-06-23T20:12:40.463+0000 */
    };
    /* 後邊代碼略過 */
}

運行看數據：


{ 
    "_id" : ObjectId("5ef1f1b9a75023095e995d9f"), 
    "title" : "Demo", 
    "content" : "Demo content", 
    "favor" : NumberInt(100), 
    "author" : {
        "name" : "WangPlus", 
        "contacts" : [
            {
                "mobile" : "13800000000"
            }, 
            {
                "mobile" : "13811111111"
            }
        ]
    }, 
    "tag" : "CSharp", 
    "post_time" : ISODate("2020-06-23T12:12:40.463+0000")
}

對比代碼時間和數據時間，會發現這兩個時間差了8小時 - 正好的中國的時區時間。


 


MongoDB規定，在數據集中存儲時間時，只會保存UTC時間。


如果只是保存（像上邊這樣），或者查詢時使用時間作為條件（例如查詢post_time < DateTime.Now的數據）時，是可以使用的，不會出現問題。


但是，如果是查詢結果中有時間字段，那這個字段，會被DateTime默認設置為DateTimeKind.Unspecified類型。而這個類型，是無時區信息的，輸出显示時，會造成混亂。


為了避免這種情況，在進行時間字段的映射時，需要加上屬性：


[BsonDateTimeOptions(Kind = DateTimeKind.Local)]
public DateTime post_time { get; set; }

這樣做，會強制DateTime類型的字段為DateTimeKind.Local類型。這時候，從显示到使用就正確了。


 


但是，別高興的太早，這兒還有一個但是。


這個但是是這樣的：數據集中存放的是UTC時間，跟我們正常的時間有8小時時差，如果我們需要按日統計，比方每天的銷售額/點擊量，怎麼搞？上面的方式，解決不了。


當然，基於MongoDB自由的字段處理，可以把需要統計的字段，按年月日時分秒拆開存放，像下面這樣的：


class Post_Time
{
    public int year { get; set; }
    public int month { get; set; }
    public int day { get; set; }
    public int hour { get; set; }
    public int minute { get; set; }
    public int second { get; set; }
}

能解決，但是Low哭了有沒有？


 


下面，終極方案來了。它就是：改寫MongoDB中對於DateTime字段的序列化類。噹噹當～～～


先創建一個類MyDateTimeSerializer：


public class MyDateTimeSerializer : DateTimeSerializer
{
    public override DateTime Deserialize(BsonDeserializationContext context, BsonDeserializationArgs args)
    {
        var obj = base.Deserialize(context, args);
        return new DateTime(obj.Ticks, DateTimeKind.Unspecified);
    }
    public override void Serialize(BsonSerializationContext context, BsonSerializationArgs args, DateTime value)
    {
        var utcValue = new DateTime(value.Ticks, DateTimeKind.Utc);
        base.Serialize(context, args, utcValue);
    }
}

代碼簡單，一看就懂。


注意，使用這個方法，上邊那個對於時間加的屬性[BsonDateTimeOptions(Kind = DateTimeKind.Local)]一定不要添加，要不然就等着哭吧:P


創建完了，怎麼用？


如果你只想對某個特定映射的特定字段使用，比方只對CollectionModel的post_time字段來使用，可以這麼寫：


[BsonSerializer(typeof(MyDateTimeSerializer))]
public DateTime post_time { get; set; }

或者全局使用：


BsonSerializer.RegisterSerializer(typeof(DateTime), new MongoDBDateTimeSerializer());

BsonSerializer是MongoDB.Driver的全局對象。所以這個代碼，可以放到使用數據庫前的任何地方。例如在Demo中，我放在Main里了：


static async Task Main(string[] args)
{
    BsonSerializer.RegisterSerializer(typeof(DateTime), new MyDateTimeSerializer());

    await Demo();
    Console.ReadKey();
}

這回看數據，數據集中的post_time跟當前時間显示完全一樣了，你統計，你分組，可以隨便霍霍了。


7. Dictionary字段


這個需求很奇怪。我們希望在一個Key-Value的文檔中，保存一個Key-Value的數據。但這個需求又是真實存在的，比方保存一個用戶的標籤和標籤對應的命中次數。


數據聲明很簡單：


public Dictionary<string, int> extra_info { get; set; }

MongoDB定義了三種保存屬性：Document、ArrayOfDocuments、ArrayOfArrays，默認是Document。


屬性寫法是這樣的：


[BsonDictionaryOptions(DictionaryRepresentation.ArrayOfDocuments)]
public Dictionary<string, int> extra_info { get; set; }

這三種屬性下，保存在數據集中的數據結構有區別。


DictionaryRepresentation.Document：


{ 
    "extra_info" : {
        "type" : NumberInt(1), 
        "mode" : NumberInt(2)
    }
}

DictionaryRepresentation.ArrayOfDocuments：


{ 
    "extra_info" : [
        {
            "k" : "type", 
            "v" : NumberInt(1)
        }, 
        {
            "k" : "mode", 
            "v" : NumberInt(2)
        }
    ]
}

DictionaryRepresentation.ArrayOfArrays：


{ 
    "extra_info" : [
        [
            "type", 
            NumberInt(1)
        ], 
        [
            "mode", 
            NumberInt(2)
        ]
    ]
}

這三種方式，從數據保存上並沒有什麼區別，但從查詢來講，如果這個字段需要進行查詢，那三種方式區別很大。


如果採用BsonDocument方式查詢，DictionaryRepresentation.Document無疑是寫着最方便的。


如果用Builder方式查詢，DictionaryRepresentation.ArrayOfDocuments是最容易寫的。


DictionaryRepresentation.ArrayOfArrays就算了。數組套數組，查詢條件寫死人。


我自己在使用時，多數情況用DictionaryRepresentation.ArrayOfDocuments。


五、其它映射屬性


上一章介紹了數據映射的完整內容。除了這些內容，MongoDB還給出了一些映射屬性，供大家看心情使用。


1. BsonElement屬性


這個屬性是用來改數據集中的字段名稱用的。


看代碼：


[BsonElement("pt")]
public DateTime post_time { get; set; }

在不加BsonElement的情況下，通過數據映射寫到數據集中的文檔，字段名就是變量名，上面這個例子，字段名就是post_time。


加上BsonElement后，數據集中的字段名會變為pt。


2. BsonDefaultValue屬性


看名稱就知道，這是用來設置字段的默認值的。


看代碼：


[BsonDefaultValue("This is a default title")]
public string title { get; set; }

當寫入的時候，如果映射中不傳入值，則數據庫會把這個默認值存到數據集中。


3. BsonRepresentation屬性


這個屬性是用來在映射類中的數據類型和數據集中的數據類型做轉換的。


看代碼：


[BsonRepresentation(BsonType.String)]
public int favor { get; set; }

這段代表表示，在映射類中，favor字段是int類型的，而存到數據集中，會保存為string類型。


前邊Decimal轉換和枚舉轉換，就是用的這個屬性。


4. BsonIgnore屬性


這個屬性用來忽略某些字段。忽略的意思是：映射類中某些字段，不希望被保存到數據集中。


看代碼：


[BsonIgnore]
public string ignore_string { get; set; }

這樣，在保存數據時，字段ignore_string就不會被保存到數據集中。


六、總結


數據映射本身沒什麼新鮮的內容，但在MongoDB中，如果用好了映射，開發過程從效率到爽的程度，都不是SQL可以相比的。正所謂：


一入Mongo深似海，從此SQL是路人。


 


謝謝大家！


（全文完）


 


本文的配套代碼在https://github.com/humornif/Demo-Code/tree/master/0015/demo


 


 









微信公眾號：老王Plus

掃描二維碼，關注個人公眾號，可以第一時間得到最新的個人文章和內容推送

本文版權歸作者所有，轉載請保留此聲明和原文鏈接
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理



【其他文章推薦】



※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!



※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線



※Google地圖已可更新顯示潭子電動車充電站設置地點!!



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



※別再煩惱如何寫文案,掌握八大原則!


Orignal From: MongoDB via Dotnet Core數據映射詳解

留言

張貼留言

這個網誌中的熱門文章

有了四步解題法模板，再也不害怕動態規劃！（看不懂算我輸）

導言 動態規劃問題一直是算法面試當中的重點和難點，並且動態規劃這種通過空間換取時間的算法思想在實際的工作中也會被頻繁用到，這篇文章的目的主要是解釋清楚 什麼是動態規劃 ，還有就是面對一道動態規劃問題，一般的 思考步驟 以及其中的注意事項等等，最後通過幾道題目將理論和實踐結合。 什麼是動態規劃 如果你還沒有聽說過動態規劃，或者僅僅只有耳聞，或許你可以看看 Quora 上面的這個 回答 。 How to explain dynamic 用一句話解釋動態規劃就是 " 記住你之前做過的事 "，如果更準確些，其實是 " 記住你之前得到的答案 "。 我舉個大家工作中經常遇到的例子。 在軟件開發中，大家經常會遇到一些系統配置的問題，配置不對，系統就會報錯，這個時候一般都會去 Google 或者是查閱相關的文檔，花了一定的時間將配置修改好。 過了一段時間，去到另一個系統，遇到類似的問題，這個時候已經記不清之前修改過的配置文件長什麼樣，這個時候有兩種方案，一種方案還是去 Google 或者查閱文檔，另一種方案是借鑒之前修改過的配置，第一種做法其實是萬金油，因為你遇到的任何問題其實都可以去 Google，去查閱相關文件找答案，但是這會花費一定的時間，相比之下，第二種方案肯定會更加地節約時間，但是這個方案是有條件的，條件如下： 之前的問題和當前的問題有着關聯性，換句話說，之前問題得到的答案可以幫助解決當前問題 需要記錄之前問題的答案 當然在這個例子中，可以看到的是，上面這兩個條件均滿足，大可去到之前配置過的文件中，將配置拷貝過來，然後做些細微的調整即可解決當前問題，節約了大量的時間。 不知道你是否從這些描述中發現，對於一個動態規劃問題，我們只需要從兩個方面考慮，那就是 找出問題之間的聯繫 ，以及 記錄答案 ，這裏的難點其實是找出問題之間的聯繫，記錄答案只是順帶的事情，利用一些簡單的數據結構就可以做到。 概念 上面的解釋如果大家可以理解的話，接    動態規劃 算法是通過拆分問題，定義問題狀態和狀態之間的關係，使得問題能夠以遞推（或者說分治）的方式去解決。它的幾個重要概念如下所述。    階段： 對於一個完整的問題過程，適當的切分為若干個相互聯繫的子問題，每次在求解一個子問題...
張貼留言
閱讀完整內容

計算機本地文件快要滅絕了

　　 編者按： 文件是数字世界的基石，是我們基本的工作單位。但是，隨着互聯網的雲化、平台化、服務化，文件日益變得可有可無。這樣一種改變究竟好不好呢？喜歡懷舊的 Simon Pitt 開始回顧各種文件的好處，哪怕這讓他顯得不合時宜。原文發表在 medium 上，標題是：Computer Files Are Going Extinct 　　我喜歡文件。我喜歡對文件重命名、移動、排序，改變它們在文件夾中的显示方式，去備份文件，將之上傳到互聯網，恢復它們，對其進行複製，甚至還可以對文件進行碎片整理。作為信息存儲方式的一種隱喻，在我看來文件是很出色的。我喜歡把文件當作一個工作單位。如果我要寫篇文章，文章會放在文件裏面。如果我要生成圖像，圖像會保存進文件裏面。 　　 謳歌 files.doc 　　文件是擬物化的。這是個很花哨的詞，只是用來表示文件是反映現實物品的一個数字概念。比方說，Word 文檔就像一張紙，躺在你的辦公桌上（desktop）。JPEG 就像一幅畫，等等。它們每個都有一個小圖標，圖標的樣子看起來像它們所代表的現實物品。一堆紙，一個畫框，一個馬尼拉文件夾。真的挺很迷人的。 　　我喜歡文件的一點是，不管裏面有什麼，跟文件的交互方式總是一致的。我上面提到的那些東西——複製、排序、碎片整理——我可以對任何文件進行那些處理。文件可能是圖像、遊戲的一部分、也可能是我最喜歡的餐具清單。碎片整理程序不在乎它是什麼。它不會去判斷內容。 　　自從我開始在 Windows 95 裏面創建文件以來，我就一直都很喜歡文件。但是我注意到我們已經開始慢慢地遠離把文件當作基本工作單位的做法。 Windows95。我的計算機 　　 services.mp3 的興起 　　十幾歲的時候，我開始痴迷於收集和管理数字音樂：我收藏 MP3 文件。一大堆的 128 kbps MP3 文件。如果你足夠幸運，有自己的 CD 刻錄機的話，就可以將它們刻錄到 CD 上，然後在朋友之間傳遞。一張 CD 可以容納 700 MB。這相當於將近 500 張軟盤！ 　　我會仔細端詳我的收藏，然後煞費苦心地給它們添加上 IDv1 和 IDv2 音樂標籤。隨着時間的流逝，大家開始開發可以在雲端自動獲取曲目列表的工具，這樣你就可以檢查和驗證 MP3 的質量。有時候我甚至會去聽那些該死的東西，儘管...
張貼留言
閱讀完整內容

純電動 Mini Cooper SE 將成為中國國產車，年產 16 萬輛

BMW 集團與中國長城汽車合資，將於江蘇建立新廠，專門投入生產 MINI Cooper SE 和部分長城品牌電動車，預計於 2022 年完工並投入生產，每年將可生產 16 萬輛電動車。 靈動可愛的 Mini Cooper，在許多車迷心中都有著特殊的地位，今年 7 月發表了首款純電動版本的 Mini Cooper SE 之後，獲得熱烈迴響，預訂數量已接近 8 萬台，顯示大家對於純電 Mini 的熱愛，因為油電版的 Mini Cooper Countryman 的全球總銷售量也才 3 萬出頭。 Mini Cooper SE 之前公布了官方定價，最低從 27,900 歐元起算，美國售價約 29,900 美元。相比現有的三門款，只貴了一成左右。然而，三年後，中國消費者將有機會買到最便宜的電動 Mini。 電動 Mini Cooper SE 最低價是 27,900 歐元，扣掉全額補助最低可以到 24,400 歐元。 BMW 集團與中國長城汽車集團於 2018 年宣布，將組建合資公司光束汽車，投入在中國的電動車生產計畫，而現在他們正式宣布啟動計畫，於江蘇張家港打造一個新工廠，全部投入電動車的製造，包括了 Mini Cooper SE 和其他長城汽車旗下的電動車。 目前的電動 Mini 只在英國牛津工廠製造，不難想像當產能轉移到中國後，Mini Cooper SE 的價格將有機會進一步調降，來競爭全球最大的電動車市場。這座屬於合資公司光束汽車的新工廠，採用一個新的產銷模式，由 BMW 和長城共同合作開發、設計、製造新產品，但是銷售通路完全沿用原本的品牌渠道。 換句話說，2020 年到 2022 年銷售的電動 Mini，將會是英國製造，而 2022 年後就會有中國製造版本開賣，考量到 Mini 在中國每年約有 30 萬輛的銷售額，同時油電版的 Coutryman 銷量更佔了全球將近五分之一，無怪乎 BMW 會想在最接近主要市場的地方蓋工廠囉。 外型完美復刻油車版 最後，簡單介紹一下 Mini Cooper SE 這台車。Mini 在電動化的路上，盡力保持著跟經典造型一致的設計，畢竟大家愛的就是它的設計。電動版的 Mini 車頭、車身跟車屁股都多了一個黃色的插頭標誌，車頭的氣壩則變成封閉式設計，除此之外，幾乎看不出來差別，連馬達...
張貼留言
閱讀完整內容