2010-09-24 33 views
5

Tôi thấy thuật ngữ này thường được sử dụng như thể có một sự phân biệt cụ thể giữa hai khi thảo luận về MVC cho các ngôn ngữ OO. Từ những gì tôi nhận được từ bối cảnh đó là các mô hình kinh doanh thực hiện một hành động để thay đổi các mô hình dữ liệu. Đó là một cách chính xác để thể hiện sự khác biệt.Làm cách nào để xác định sự khác biệt giữa mô hình kinh doanh và mô hình dữ liệu?

Tôi đoán điều gây nhầm lẫn là mặc dù hầu hết các ví dụ về mô hình đều kết hợp cả hai vai trò này và trên bề mặt mà nó cảm thấy tự nhiên. Thông thường, các phương thức thay đổi trạng thái đối tượng nằm bên trong chính các đối tượng đó. Tôi đoán tôi gặp khó khăn trong việc đưa ra một ví dụ về cách thức hoạt động của nó trong thế giới thực. Có vẻ như tự nhiên hơn là các phương pháp để thay đổi một đối tượng nằm bên trong đối tượng đó. Có thể giải thích rõ hơn một chút về điều này không?

+0

Mô hình kinh doanh và mô hình Dữ liệu không liên quan gì đến MVC. Nó không quan trọng những gì kết thúc trước là (MVC, Silverlight, ...), nó phải được tách ra từ lớp kinh doanh của bạn và lớp dữ liệu. – Martin

+0

Khi bạn nói rằng "thường thì các phương thức thay đổi trạng thái đối tượng nằm bên trong chính các đối tượng đó", bạn có thể nói về mẫu Active Record. Vui lòng xem câu trả lời của tôi bên dưới. – rsenna

+0

Điều thú vị là tất cả các câu trả lời, cho đến nay, giả sử việc sử dụng một cơ sở dữ liệu. Tôi không biết rằng mô hình dữ liệu liên quan nhất thiết đến cơ sở dữ liệu. Một số chương trình, thậm chí các chương trình lớn với kiến ​​trúc tuyệt vời không sử dụng cơ sở dữ liệu chút nào, một số thậm chí không lưu dữ liệu. Vì vậy, điều này có nghĩa là họ không có mô hình dữ liệu. Tôi không có ý nói điều này một cách thô lỗ, nhưng nó khiến tôi tự hỏi làm thế nào điều này áp dụng cho các ứng dụng nói chung và không chỉ những người làm việc sử dụng một cơ sở dữ liệu ... – startoftext

Trả lời

0

Mô hình kinh doanh bao gồm cách luồng dữ liệu di chuyển trong các chức năng của doanh nghiệp. Việc này không xem xét mô hình dữ liệu, nhưng sẽ giúp hướng dẫn cách dữ liệu được lưu trữ.

Mô hình dữ liệu được xây dựng với dữ liệu trong tâm trí - nơi logic của mô hình kinh doanh dựa trên quy trình/quy trình/chỉ dòng chảy của mọi thứ được thực hiện, mô hình dữ liệu được thiết kế để cấu trúc dữ liệu cách có thể sẽ phản ánh nhu cầu của mô hình kinh doanh.

1

"Mô hình kinh doanh" và "Mô hình dữ liệu" có thể được xem là các cấp phụ của cấp "M", trong ứng dụng MVC. Cả hai đều liên quan đến việc lưu và tải dữ liệu. Sự khác biệt là đầu tiên là gần gũi hơn với cách các yêu cầu và chức năng được nhìn thấy bởi người dùng cuối, và thứ hai là gần gũi hơn với thao tác cơ sở dữ liệu cấp thấp.

Lớp Mô hình dữ liệu luôn phụ thuộc nhiều hơn vào cách cụ thể mà dữ liệu được duy trì trong một ứng dụng. Bắt đầu từ cơ sở dữ liệu (hoặc bất cứ cách nào là cách cụ thể của bạn để lưu giữ dữ liệu - nó có thể là các tệp phẳng hoặc XML), nó là tầng phần mềm trừu tượng đầu tiên. Ví dụ, nếu bạn đang sử dụng Oracle RDBMS trên một ứng dụng, mô hình dữ liệu là nơi bạn sẽ đặt bất kỳ đặc trưng của Oracle, như các câu lệnh SQL cụ thể, kết nối v.v ... Đó cũng là nơi để thực hiện thao tác dữ liệu nguyên tử.). Tất nhiên, có nhiều cách để làm cho tầng này phụ thuộc ít hơn vào một RDBMS đã cho, như sử dụng một số loại thư viện ORM như Hibernate (Java), NHibernate (.NET) hoặc Doctrine (PHP).

Quá "mức thấp", mô hình dữ liệu KHÔNG được sử dụng trực tiếp bởi phần còn lại của ứng dụng. Đây là vai trò của Mô hình kinh doanh.

Mô hình kinh doanh được đặt ở cấp độ trừu tượng cao hơn. Nó thực hiện các dịch vụ đóng gói tất cả các yêu cầu chức năng cần thiết cho ứng dụng.

Mô hình kinh doanh không được phụ thuộc vào RDBMS cụ thể - nó nên sử dụng Mô hình dữ liệu để thực hiện công việc này. Một sự khác biệt khác là nó cho thấy các phương thức chi tiết hơn - không phải các công cụ CRUD, mà là chức năng phụ thuộc kinh doanh phức tạp hơn. Tất nhiên, nó cũng không nên phụ thuộc vào lớp trình bày (khung nhìn và bộ điều khiển). Ví dụ, một phương pháp thay đổi mức lương của một nhân viên, dựa trên giá trị bằng chữ, có lẽ thuộc về mô hình dữ liệu (xem xét chức năng đó không được phép cho người dùng cuối). Nhưng một phương pháp để tăng tất cả tiền lương trên một tỷ lệ nhất định chắc chắn sẽ thuộc về mô hình kinh doanh (và nó có thể lặp lại tất cả nhân viên, và sử dụng đầu tiên, "cập nhật nhân viên đơn lẻ", phương pháp mô hình dữ liệu để thực thi quy tắc này). .

Nhưng hãy nhớ đây là mô tả "theo sách" - các tình huống thực tế khác nhau. Và đôi khi chúng tôi có thể không cần hai tầng dữ liệu riêng biệt - ví dụ mẫu ActiveRecord, có thể được sử dụng như cả lớp Mô hình Dữ liệu và dưới dạng lớp Doanh nghiệp.Trong trường hợp này, bạn sẽ kết hợp cả hai tầng thành một duy nhất - nhưng tôi chắc chắn sẽ không khuyên bạn nên sử dụng phương pháp này trên các kịch bản phức tạp hơn.

1

Mô hình trong triển khai MVC là hoặc phải là mô hình kinh doanh.

Mô hình kinh doanh mô tả hành vi và thuộc tính của các thực thể của doanh nghiệp có liên quan đến ứng dụng. Khi bạn mã hóa điều này, các thực thể trở thành các lớp và hành vi và các thuộc tính sẽ kết thúc dưới dạng các phương thức và thuộc tính của các lớp đó tương ứng.

Ứng dụng cần một nơi nào đó để lưu trữ thông tin của ứng dụng. Nếu bộ nhớ là vô hạn, chúng tôi sẽ không bao giờ bị cúp điện và hệ điều hành của chúng tôi sẽ không bao giờ yêu cầu khởi động lại, mô hình kinh doanh sẽ là đủ. Tuy nhiên, trong thế giới thực, chúng ta cần lưu trữ các thuộc tính của các lớp ở đâu đó, nơi chúng có thể tồn tại trong ứng dụng và/hoặc tắt máy tính.

Và vì vậy mô hình kinh doanh cần và sử dụng một kho dữ liệu của một số loại. Cách lưu trữ dữ liệu này được tổ chức là mô hình dữ liệu. Như trong hầu hết các trường hợp, một cơ sở dữ liệu quan hệ là kho dữ liệu được lựa chọn, mô hình dữ liệu thường là thiết kế của cơ sở dữ liệu quan hệ.

Trong khi mô hình dữ liệu có thể ở mức logic và sau đó giống mô hình kinh doanh OO chặt chẽ hơn, trong ngữ cảnh này, chúng ta thường nói về việc triển khai kỹ thuật mô hình logic. (Một khác biệt chính: các mô hình logic cho phép các mối quan hệ M-N giữa các bảng, mô hình kỹ thuật chuẩn hóa sẽ có một bảng liên kết có quan hệ N-1 với hai bảng gốc).

Bản chất OO của mô hình kinh doanh không ánh xạ trực tiếp đến thiết kế bảng và cột được chuẩn hóa. Các thư viện ORM (Object - Relational - Mapping) thường được sử dụng để ánh xạ các thuộc tính của các lớp tới các bảng và các cột trong cơ sở dữ liệu quan hệ.

Khi mô hình kinh doanh sử dụng kho dữ liệu và do đó mô hình dữ liệu, và cùng nhau chúng bao gồm Mô hình trong triển khai MVC, sự khác biệt giữa chúng thường bị mờ. Tôi nghĩ rằng rất đáng để giữ vai trò riêng biệt của họ rõ ràng trong tâm trí bạn. Nó giúp trong việc quyết định nơi logic nên đi. Ví dụ, trái với câu trả lời của rsenna, tôi sẽ nội dung rằng việc thay đổi mức lương cho một nhân viên duy nhất vẫn là một chức năng của mô hình kinh doanh, ngay cả khi thay đổi nó thành giá trị bằng chữ, bởi vì mô hình kinh doanh có thể xác định tất cả các loại kiểm tra và cân bằng, xác nhận và các quy tắc kinh doanh khác để thay đổi mức lương của nhân viên. Đối với examply doanh nghiệp có thể có quy tắc mà không có lương có thể thay đổi nhiều hơn x phần trăm, không bao giờ có thể vượt quá mức lương của Giám đốc điều hành, tuân thủ các quy tắc của Liên minh, vv. các quy tắc thuộc về mô hình kinh doanh, không nằm trong mô hình dữ liệu. DBa thích họ trong mô hình dữ liệu, có thể bởi vì mô hình kinh doanh thường được thực hiện trong một số loại ngôn ngữ lập trình và mô hình dữ liệu trong cơ sở dữ liệu và dba giống như giữ cơ sở dữ liệu của họ tốt đẹp và hợp lệ.

Tôi muốn nói rằng các quy tắc vẫn là một phần của mô hình kinh doanh, không phải là mô hình dữ liệu, nhưng tất nhiên bạn luôn có thể chọn triển khai chúng trong trình kích hoạt và thủ tục được lưu trữ. Trường hợp các quy tắc của mô hình kinh doanh được thực hiện là một vấn đề ..., thực hiện tốt, chi tiết.

+0

Tôi đã nói 'có thể thuộc về' - nếu một nhà phát triển cần cho phép một chức năng cập nhật lương của nhân viên, tất nhiên nó phải được trưng bày trên mô hình kinh doanh. Nhưng tôi đã xem xét một ứng dụng mà chức năng như vậy không được phép cho người dùng cuối - tôi đoán nó đã đủ rõ ràng, nhưng có lẽ tôi đã sai. – rsenna

+0

@rsenna: Tôi hiểu, nhưng ... nếu người dùng cuối không được phép cập nhật lương theo từng cá nhân, nhà phát triển chắc chắn không được phép làm như vậy. Nếu bạn đang suy nghĩ giải quyết thất bại thảm khốc thảm khốc, thậm chí sau đó không có nhà phát triển nào có thể cập nhật cơ sở dữ liệu sản xuất theo cách riêng của mình. Họ có thể là những người thực hiện công việc, nhưng trên cơ sở dữ liệu sản xuất tốt nhất nên được thực hiện bởi một kịch bản, được xác nhận bởi một nhà phát triển không để tạo ra kết quả mong muốn và được phát hành theo tài khoản/ủy quyền của người quản lý (ví dụ: người quản lý nhân sự trong trường hợp tiền lương) –

+0

@rsenna: có lẽ tôi đã đọc bình luận của bạn sai "một nhà phát triển cho phép người dùng cuối", khiến tôi suy nghĩ theo một hướng cụ thể. Tuy nhiên, nếu các bản cập nhật tiền lương của nhân viên không được phép cho bất kỳ người dùng cuối nào, họ sẽ không thể thực hiện được. Và phục hồi thất bại nên được bao quanh với các thủ tục thích hợp và không để lại cho bất kỳ nhà phát triển đơn/dba. –

Các vấn đề liên quan