Dữ liệu tồn tại trong Smalltalk/Seaside

Question

Tôi đã dành thời gian gần đây để làm quen với Smalltalk và Seaside. Tôi đến từ thế giới Java EE và như bạn có thể tưởng tượng nó đã được thử thách nhận được tâm trí của tôi xung quanh một số khái niệm Smalltalk. :)

Hiện tại, tôi đang cố gắng nắm bắt sự kiên trì dữ liệu thường được triển khai nhất trong thế giới Smalltalk. Giả định đối với tôi như một lập trình viên Java là sử dụng RDMS (ví dụ MySQL) và ORM (ví dụ: Hibernate). Tôi hiểu rằng đó không phải là trường hợp cho Smalltalk (sử dụng Hibernate ít nhất). Tôi không nhất thiết phải tìm kiếm phương pháp bản đồ chặt chẽ nhất với cách thức được thực hiện trong Java EE.

Phổ biến nhất là lưu dữ liệu vào hình ảnh, cửa hàng đối tượng hoặc RDMS? Nó thậm chí là điển hình cho các ứng dụng Smalltalk để sử dụng RDMS?

Tôi hiểu không có cách tiếp cận phù hợp với tất cả mọi thứ ở đây và chiến lược kiên trì phù hợp sẽ phụ thuộc vào nhu cầu của ứng dụng (số lượng dữ liệu, đồng thời, v.v.). Cách tiếp cận tốt có thể bắt đầu đơn giản nhưng cũng có quy mô là gì?

Tôi đã xem một số video của Avi Bryant thảo luận về chiến lược mà ông đã sử dụng để duy trì và mở rộng quy mô DabbleDB. Từ những gì tôi hiểu, dữ liệu của khách hàng đã được lưu ngay vào hình ảnh (một hình ảnh cho mỗi khách hàng). Điều đó làm việc trong trường hợp sử dụng của anh ta vì khách hàng không phải chia sẻ dữ liệu. Đây có phải là cách tiếp cận chung không?

Hy vọng tôi không tạo TLDR này. Rất cám ơn sự hiểu biết sâu sắc mà các bạn Smalltalk đã cung cấp trong các câu hỏi trước đây của tôi. Nó được đánh giá cao.

Answer 1

Justin,

đừng lo lắng, Smalltalk không phải là hình thức rất khác nhau ngôn ngữ khác trong lĩnh vực này, nó chỉ bổ sung thêm tùy chọn bền bỉ ảnh dựa.

Có những người lập bản đồ O/R như Hibernate cho Smalltalk, GLORP và cổng Pharo DBXtalk của nó chắc chắn là những cái phổ biến nhất trong những ngày này. Đây sẽ cảm thấy rất thoải mái cho bạn nếu bạn biết Hibernate.

Sau đó, có các giải pháp OODB như GemStone hoặc Magma DB hoặc VOSS và nhiều thứ khác cho phép bạn để lại tất cả các vấn đề về bản đồ O/R. Hầu hết trong số này là khá hạn chế để lưu trữ các đối tượng Smalltalk, GemStone là một ngoại lệ trong việc cung cấp cầu nối cho Ruby và các ngôn ngữ khác.

Ngoài ra còn có các công cụ để lưu trữ các đối tượng Smalltalk trong cơ sở dữ liệu NoSQL hiện đại như CouchDB, Cassandra, HÀNG HOẶC các loại khác. Bí quyết ở đây chỉ là việc chuyển đổi các giá trị đối tượng Smalltalk thành luồng JSON và một yêu cầu HTTP nhỏ.

Cuối cùng, có tùy chọn lưu hình ảnh Smalltalk hoàn chỉnh của bạn. Tôi muốn nói rằng bạn có thể làm điều đó trong một môi trường sản xuất, nhưng nó không phải là cách tiêu chuẩn hoặc ưa thích của đồng nó cho nhiều người. Bạn làm điều đó rất nhiều trong phát triển, bởi vì bạn chỉ có thể lưu một hình ảnh và tiếp tục công việc của bạn vào lần sau chính xác với tất cả các đối tượng tại chỗ như bạn đã có chúng khi bạn lưu.

Vì vậy, dòng cơ bản là: Tất cả các tùy chọn lưu trữ mà bạn biết đều có sẵn trong Smalltalk, cộng thêm một tùy chọn.

Joachim

Answer 2

Tôi đoán nó về cơ bản phụ thuộc vào độ lớn DB của bạn sẽ được và những gì loại tải nó sẽ được xử lý.

Trong trường hợp của tôi, tất cả các ứng dụng tôi từng viết đều sử dụng hình ảnh kiên trì với tuần tự đĩa. Về cơ bản, bạn chỉ cần tuần tự hóa các đối tượng của mình bằng cách sử dụng Nhiên liệu theo yêu cầu.Trong trường hợp của tôi, tôi làm như vậy mỗi khi một phần dữ liệu quan trọng được xử lý, cộng với một quy trình thông thường sẽ tuần tự hóa chúng sau mỗi 24 giờ. Hình ảnh cũng được lưu tự động sau mỗi 24 giờ. Ứng dụng lớn nhất mà tôi viết bằng cách sử dụng phương pháp này là xử lý tất cả các quy trình kinh doanh của một công ty nhỏ gồm 10 công nhân và khoảng 50 dịch giả tự do đã sử dụng nó mỗi ngày trong một năm rưỡi. Khối lượng công việc là khá "lớn" trong tài khoản các ứng dụng giao dịch với các tập tin lớn tất cả các thời gian, nhưng các ứng dụng đã ở lại ổn định và nhanh chóng. Chuyển sang một máy chủ mới và cập nhật hình ảnh Pharo dễ dàng như việc đưa dự án trở về từ monticello và thực hiện "cơ sở dữ liệu" được tuần tự hóa mới nhất. Theo quan điểm của tôi, ORM là một nỗi đau không cần thiết, chúng ta đang ở trong thế giới đối tượng, và phải làm phẳng các đối tượng của chúng ta cảm thấy sai, đặc biệt khi chúng ta có các giải pháp hướng đối tượng tốt đẹp.

Vì vậy, nếu ứng dụng của bạn xử lý một lượng dữ liệu khá nhỏ, tôi sẽ đề xuất phương pháp đơn giản của tôi hoặc SandstoneDB. Nếu ứng dụng của bạn giao dịch với số lượng lớn các giao dịch và dữ liệu, tôi sẽ sử dụng Gemstone.

Chỉ hai xu của tôi.

Answer 3

Ramon Leon mô tả tình huống, chiến lược cơ bản và sự cân bằng của họ một cách đẹp mắt in his blog post.

Tôi sẽ bắt đầu với khung công tác Persistence dựa trên hình ảnh đơn giản của mình, mà tôi ported và sử dụng trong Pharo 1.3. Mariano Martinez Peck gần đây đã điều chỉnh nó để sử dụng Fuel (cùng một liên kết). Nó rất đơn giản, thực hiện công việc, và mang lại cho tôi nhiều tự tin hơn để chơi trong hình ảnh của tôi, biết rằng ngay cả khi tôi vĩnh viễn làm hỏng nó, tất cả các dữ liệu của tôi là an toàn. Tôi chỉ cần sao chép các thư mục dữ liệu vào thư mục hình ảnh mới, tải các gói của tôi và tất cả các đối tượng của tôi vẫn còn sống trong hình ảnh mới.