Tại sao chúng ta cần các đối tượng thực thể? [đóng cửa]

Tôi thực sự cần phải xem một số cuộc tranh luận trung thực, chu đáo về giá trị của mô hình thiết kế ứng dụng doanh nghiệp hiện đang được chấp nhận .

Tôi không tin rằng các đối tượng thực thể nên tồn tại.

Theo các đối tượng thực thể, ý tôi là những thứ điển hình mà chúng ta có xu hướng xây dựng cho các ứng dụng của mình, như "Người", "Tài khoản", "Đặt hàng", v.v.

Triết lý thiết kế hiện tại của tôi là thế này:

• Tất cả các truy cập cơ sở dữ liệu phải được thực hiện thông qua các thủ tục được lưu trữ.
• Bất cứ khi nào bạn cần dữ liệu, hãy gọi một thủ tục được lưu trữ và lặp lại qua SqlDataReader hoặc các hàng trong DataTable

(Lưu ý: Tôi cũng đã xây dựng các ứng dụng doanh nghiệp với Java EE, mọi người java vui lòng thay thế đẳng thức cho các ví dụ .NET của tôi)

Tôi không chống OO. Tôi viết rất nhiều lớp cho các mục đích khác nhau, không phải là các thực thể. Tôi sẽ thừa nhận rằng một phần lớn các lớp tôi viết là các lớp trợ giúp tĩnh.

Tôi không xây dựng đồ chơi. Tôi đang nói về các ứng dụng giao dịch lớn, khối lượng lớn được triển khai trên nhiều máy. Các ứng dụng web, dịch vụ windows, dịch vụ web, tương tác b2b, bạn đặt tên cho nó.

Tôi đã sử dụng HOẶC Mappers. Tôi đã viết một vài. Tôi đã sử dụng ngăn xếp Java EE, CSLA và một vài tương đương khác. Tôi không chỉ sử dụng chúng mà còn tích cực phát triển và duy trì các ứng dụng này trong môi trường sản xuất.

Tôi đã đi đến kết luận đã được thử nghiệm trong trận chiến rằng các đối tượng thực thể đang cản trở chúng ta và cuộc sống của chúng ta sẽ trở nên dễ dàng hơn rất nhiều nếu không có chúng.

Xem xét ví dụ đơn giản này: bạn nhận được một cuộc gọi hỗ trợ về một trang nhất định trong ứng dụng của bạn không hoạt động chính xác, có thể một trong các trường không được duy trì như vậy. Với mô hình của tôi, nhà phát triển được chỉ định để tìm sự cố sẽ mở chính xác 3 tệp . Một tệp ASPX, một tệp ASPX.CS và tệp SQL có thủ tục được lưu trữ. Vấn đề, có thể là một tham số bị thiếu đối với cuộc gọi thủ tục được lưu trữ, mất vài phút để giải quyết. Nhưng với bất kỳ mô hình thực thể nào, bạn sẽ luôn kích hoạt trình gỡ lỗi, bắt đầu chuyển qua mã và bạn có thể kết thúc với 15-20 tệp được mở trong Visual Studio. Khi bạn bước xuống dưới cùng của ngăn xếp, bạn đã quên nơi bạn bắt đầu. Chúng ta chỉ có thể giữ rất nhiều thứ trong đầu cùng một lúc. Phần mềm cực kỳ phức tạp mà không cần thêm bất kỳ lớp không cần thiết.

Sự phức tạp phát triển và xử lý sự cố chỉ là một mặt của sự kìm kẹp của tôi.

Bây giờ hãy nói về khả năng mở rộng.

Các nhà phát triển có nhận ra rằng mỗi lần họ viết hoặc sửa đổi bất kỳ mã nào tương tác với cơ sở dữ liệu, họ cần thực hiện một phân tích khủng khiếp về tác động chính xác trên cơ sở dữ liệu? Và không chỉ là bản sao phát triển, ý tôi là bắt chước sản xuất, vì vậy bạn có thể thấy rằng cột bổ sung mà bạn yêu cầu cho đối tượng của mình vừa vô hiệu hóa kế hoạch truy vấn hiện tại và một báo cáo đang chạy trong 1 giây sẽ chỉ mất 2 phút bởi vì bạn đã thêm một cột vào danh sách chọn? Và hóa ra chỉ số bạn yêu cầu bây giờ lớn đến mức DBA sẽ phải sửa đổi bố cục vật lý của các tệp của bạn?

Nếu bạn để mọi người ở quá xa kho lưu trữ dữ liệu vật lý với sự trừu tượng hóa, họ sẽ tạo ra sự tàn phá với một ứng dụng cần mở rộng quy mô.

Tôi không phải là một người nhiệt tâm. Tôi có thể bị thuyết phục nếu tôi sai, và có lẽ tôi, vì có sự thúc đẩy mạnh mẽ như vậy đối với Linq đối với Sql, ADO.NET EF, Hibernate, Java EE, v.v. Hãy suy nghĩ qua các phản hồi của bạn, nếu tôi thiếu điều gì đó thực sự muốn biết nó là gì và tại sao tôi nên thay đổi suy nghĩ của mình.

[Biên tập]

Có vẻ như câu hỏi này đột nhiên hoạt động trở lại, vì vậy bây giờ chúng tôi có tính năng bình luận mới, tôi đã nhận xét trực tiếp trên một số câu trả lời. Cảm ơn đã trả lời, tôi nghĩ rằng đây là một cuộc thảo luận lành mạnh.

Tôi có lẽ nên rõ ràng hơn rằng tôi đang nói về các ứng dụng doanh nghiệp. Tôi thực sự không thể nhận xét về một trò chơi đang chạy trên máy tính để bàn của ai đó hoặc ứng dụng dành cho thiết bị di động.

Một điều tôi phải đưa lên đây ở đầu để trả lời cho một số câu trả lời tương tự: tính trực giao và tách biệt các mối quan tâm thường được trích dẫn là lý do để đi thực thể / ORM. Đối với tôi, các thủ tục được lưu trữ là ví dụ tốt nhất về sự tách biệt các mối quan tâm mà tôi có thể nghĩ ra. Nếu bạn không cho phép tất cả các quyền truy cập khác vào cơ sở dữ liệu, ngoài các thủ tục được lưu trữ, về mặt lý thuyết, bạn có thể thiết kế lại toàn bộ mô hình dữ liệu của mình và không phá vỡ bất kỳ mã nào, miễn là bạn duy trì đầu vào và đầu ra của các thủ tục được lưu trữ. Chúng là một ví dụ hoàn hảo về lập trình theo hợp đồng (chỉ cần bạn tránh "chọn *" và ghi lại các tập kết quả).

Hỏi ai đó đã ở trong ngành trong một thời gian dài và đã làm việc với các ứng dụng tồn tại lâu dài: có bao nhiêu lớp ứng dụng và giao diện người dùng đã đến và đi trong khi cơ sở dữ liệu đã tồn tại? Việc điều chỉnh và cấu trúc lại cơ sở dữ liệu khó đến mức nào khi có 4 hoặc 5 lớp kiên trì khác nhau tạo SQL để lấy dữ liệu? Bạn không thể thay đổi bất cứ điều gì! ORM hoặc bất kỳ mã nào tạo SQL khóa cơ sở dữ liệu của bạn trong đá .

Tôi nghĩ rằng vấn đề "logic" của ứng dụng phức tạp đến mức nào và nơi bạn đã triển khai nó. Nếu tất cả logic của bạn nằm trong các thủ tục được lưu trữ và tất cả các ứng dụng của bạn thực hiện việc gọi các thủ tục đó và hiển thị kết quả, thì việc phát triển các đối tượng thực thể thực sự là một sự lãng phí thời gian. Nhưng đối với một ứng dụng mà các đối tượng có tương tác phong phú với nhau và cơ sở dữ liệu chỉ là một cơ chế bền vững, có thể có giá trị để có các đối tượng đó.

Vì vậy, tôi muốn nói rằng không có câu trả lời nào phù hợp cho tất cả mọi người. Các nhà phát triển cần phải nhận thức rằng, đôi khi, cố gắng quá OO có thể gây ra nhiều vấn đề hơn nó giải quyết.

Lý thuyết nói rằng các triển khai liên kết chặt chẽ, lỏng lẻo là con đường phía trước.

Vì vậy, tôi cho rằng bạn đang đặt câu hỏi về cách tiếp cận đó, cụ thể là tách biệt mối quan tâm.

Tệp aspx.cs của tôi có nên tương tác với cơ sở dữ liệu, gọi một sproc và hiểu IDataReader không?

Trong môi trường nhóm, đặc biệt là nơi bạn có ít người kỹ thuật xử lý phần aspx của ứng dụng, tôi không cần những người này có thể "chạm" vào công cụ này.

Tách tên miền của tôi khỏi cơ sở dữ liệu của tôi bảo vệ tôi khỏi những thay đổi cấu trúc trong cơ sở dữ liệu, chắc chắn là một điều tốt? Chắc chắn hiệu quả của cơ sở dữ liệu là vô cùng quan trọng, vì vậy hãy để một người xuất sắc nhất trong công cụ đó giải quyết vấn đề đó, ở một nơi, với càng ít tác động đến phần còn lại của hệ thống càng tốt.

Trừ khi tôi hiểu nhầm cách tiếp cận của bạn, một thay đổi cấu trúc trong cơ sở dữ liệu có thể có một khu vực tác động lớn với bề mặt ứng dụng của bạn. Tôi thấy rằng sự tách biệt mối quan tâm này cho phép tôi và nhóm của mình giảm thiểu điều này. Ngoài ra bất kỳ thành viên mới của nhóm nên hiểu cách tiếp cận này tốt hơn.

Ngoài ra, cách tiếp cận của bạn dường như ủng hộ logic kinh doanh của ứng dụng của bạn cư trú trong cơ sở dữ liệu của bạn? Điều này cảm thấy sai đối với tôi, SQL thực sự giỏi trong việc truy vấn dữ liệu, và không, imho, thể hiện logic kinh doanh.

Mặc dù suy nghĩ thú vị, mặc dù nó cảm thấy một bước đi từ SQL trong aspx, mà từ những ngày asp cũ không có cấu trúc xấu của tôi, làm tôi sợ hãi.

Một lý do - tách mô hình miền của bạn khỏi mô hình cơ sở dữ liệu của bạn.

Những gì tôi làm là sử dụng Test Driven Development để tôi viết các lớp UI và Model của mình trước và lớp Data bị chế giễu, vì vậy UI và model được xây dựng xung quanh các đối tượng cụ thể của miền, sau đó tôi ánh xạ các đối tượng này sang công nghệ mà tôi đang sử dụng Lớp dữ liệu. Đó là một ý tưởng tồi để cho cấu trúc cơ sở dữ liệu xác định thiết kế ứng dụng của bạn. Nếu có thể hãy viết ứng dụng trước và để điều đó ảnh hưởng đến cấu trúc cơ sở dữ liệu của bạn chứ không phải theo cách khác.

Đối với tôi, tôi không muốn ứng dụng của mình quan tâm đến cách lưu trữ dữ liệu. Có lẽ tôi sẽ bị tát khi nói điều này ... nhưng ứng dụng của bạn không phải là dữ liệu của bạn, dữ liệu là một tạo tác của ứng dụng. Tôi muốn ứng dụng của mình suy nghĩ về Khách hàng, Đơn hàng và Vật phẩm, không phải là một công nghệ như DataSets, DataTables và DataRows ... vì ai biết những thứ đó sẽ tồn tại trong bao lâu.

Tôi đồng ý rằng luôn có một số lượng khớp nối nhất định, nhưng tôi thích khớp nối đó hướng lên trên hơn là xuống dưới. Tôi có thể điều chỉnh các chi và lá của cây dễ dàng hơn tôi có thể thay đổi thân cây.

Tôi có xu hướng dự trữ sprocs để báo cáo vì các truy vấn có xu hướng nhanh hơn một chút so với truy cập dữ liệu chung của ứng dụng.

Tôi cũng có xu hướng suy nghĩ với việc kiểm tra đơn vị thích hợp sớm cho kịch bản đó giống như một cột không được duy trì có khả năng không phải là vấn đề.

Eric, bạn đã chết trên. Đối với bất kỳ ứng dụng thực sự có khả năng mở rộng / dễ dàng duy trì / mạnh mẽ, câu trả lời thực sự duy nhất là phân phối với tất cả rác và bám vào những điều cơ bản.

Tôi đã đi theo một quỹ đạo tương tự với sự nghiệp của mình và đã đi đến kết luận tương tự. Tất nhiên, chúng tôi coi là dị giáo và nhìn buồn cười. Nhưng công cụ của tôi hoạt động và hoạt động tốt.

Mỗi dòng mã nên được xem xét với sự nghi ngờ.

Tôi muốn trả lời với một ví dụ tương tự như ví dụ bạn đề xuất.

Trên công ty của tôi, tôi đã phải xây dựng một phần CRUD đơn giản cho các sản phẩm, tôi xây dựng tất cả các thực thể của mình và một DAL riêng. Sau đó, một nhà phát triển khác đã phải thay đổi một bảng liên quan và thậm chí anh ta đã đổi tên một số lĩnh vực. Tệp duy nhất tôi phải thay đổi để cập nhật biểu mẫu của mình là DAL cho bảng đó.

Những gì (theo ý kiến ​​của tôi) các thực thể mang đến cho một dự án là:

Ortogonality: Thay đổi trong một lớp có thể không ảnh hưởng đến các lớp khác (tất nhiên nếu bạn thực hiện một thay đổi lớn trên cơ sở dữ liệu, nó sẽ gợn qua tất cả các lớp nhưng hầu hết các thay đổi nhỏ sẽ không xảy ra).

Khả năng kiểm tra: Bạn có thể kiểm tra logic của mình mà không cần chạm vào cơ sở dữ liệu của bạn. Điều này làm tăng hiệu suất trong các bài kiểm tra của bạn (cho phép bạn chạy chúng thường xuyên hơn).

Tách biệt mối quan tâm: Trong một sản phẩm lớn, bạn có thể gán cơ sở dữ liệu cho một DBA và anh ta có thể tối ưu hóa địa ngục khỏi nó. Chỉ định Mô hình cho một chuyên gia kinh doanh có kiến ​​thức cần thiết để thiết kế nó. Chỉ định các biểu mẫu riêng lẻ cho các nhà phát triển có nhiều kinh nghiệm hơn trên biểu mẫu web, v.v.

Cuối cùng tôi muốn thêm rằng hầu hết những người lập bản đồ ORM đều hỗ trợ các thủ tục được lưu trữ vì đó là những gì bạn đang sử dụng.

Chúc mừng.

Tôi nghĩ rằng bạn có thể "cắn nhiều hơn bạn có thể nhai" về chủ đề này. Ted Neward đã không tỏ ra lúng túng khi gọi nó là " Việt Nam của Khoa học máy tính ".

Một điều tôi hoàn toàn có thể đảm bảo với bạn là nó sẽ thay đổi quan điểm của bất kỳ ai về vấn đề này, như đã được chứng minh rất thường xuyên trên vô số blog, diễn đàn, podcast, v.v.

Chắc chắn sẽ ổn khi có sự tranh cãi và tranh luận về một chủ đề gây tranh cãi, chỉ có điều này đã được thực hiện rất nhiều lần đến nỗi cả hai bên đều đồng ý không đồng ý và chỉ cần viết phần mềm.

Nếu bạn muốn đọc thêm ở cả hai phía, hãy xem các bài viết trên blog của Ted, Ayende Rahein, Jimmy Nilson, Scott Bellware, Alt.Net, Stephen Forte, Eric Evans, v.v.

@Dan, xin lỗi, đó không phải là thứ tôi đang tìm kiếm. Tôi biết lý thuyết. Tuyên bố của bạn "là một ý tưởng rất tồi" không được hỗ trợ bởi một ví dụ thực tế. Chúng tôi đang cố gắng phát triển phần mềm trong thời gian ngắn hơn, với ít người hơn, ít mắc lỗi hơn và chúng tôi muốn khả năng dễ dàng thực hiện các thay đổi. Mô hình nhiều lớp của bạn, theo kinh nghiệm của tôi, là một tiêu cực trong tất cả các loại trên. Đặc biệt là liên quan đến việc làm cho mô hình dữ liệu là điều cuối cùng bạn làm. Mô hình dữ liệu vật lý phải được xem xét quan trọng từ ngày 1.

Tôi thấy câu hỏi của bạn thực sự thú vị.
Thông thường tôi cần các đối tượng thực thể để đóng gói logic nghiệp vụ của một ứng dụng. Sẽ rất phức tạp và không đủ để đẩy logic này vào lớp dữ liệu.
Bạn sẽ làm gì để tránh các đối tượng thực thể này? Bạn có giải pháp nào trong tâm trí?

Các đối tượng thực thể có thể tạo điều kiện cho bộ đệm trên lớp ứng dụng. Chúc may mắn lưu trữ một bộ dữ liệu.

Chúng ta cũng nên nói về khái niệm thực thể là gì. Khi tôi đọc qua cuộc thảo luận này, tôi có ấn tượng rằng hầu hết mọi người ở đây đang nhìn vào các thực thể theo nghĩa của Mô hình miền thiếu máu . Rất nhiều người đang xem Mô hình miền thiếu máu như một phản mẫu!

Có giá trị trong các mô hình miền phong phú. Đó là tất cả những gì về Thiết kế hướng miền . Cá nhân tôi tin rằng OO là một cách để chinh phục sự phức tạp. Điều này có nghĩa là không chỉ phức tạp về kỹ thuật (như truy cập dữ liệu, ràng buộc ui, bảo mật ...) mà còn phức tạp trong lĩnh vực kinh doanh !

Nếu chúng ta có thể áp dụng các kỹ thuật OO để phân tích, mô hình hóa, thiết kế và thực hiện các vấn đề kinh doanh của mình, thì đây là một lợi thế to lớn cho khả năng bảo trì và mở rộng của các ứng dụng không tầm thường!

Có sự khác biệt giữa các thực thể của bạn và các bảng của bạn. Các thực thể nên đại diện cho mô hình của bạn, các bảng chỉ đại diện cho khía cạnh dữ liệu của mô hình của bạn!

Đúng là dữ liệu sống lâu hơn các ứng dụng, nhưng hãy xem xét trích dẫn này từ David Laribee : Các mô hình là mãi mãi ... dữ liệu là một tác dụng phụ hạnh phúc.

Một số liên kết khác về chủ đề này:

• Tại sao Setters và Getters là xấu xa

• Sự trở lại của OO thuần túy

• POJO so với NOJO

• Siêu mẫu Phần 2

• TDD, Mocks và Thiết kế

Câu hỏi thực sự thú vị. Thành thật tôi không thể chứng minh tại sao các thực thể là tốt. Nhưng tôi có thể chia sẻ ý kiến ​​của mình tại sao tôi thích chúng. Mã như

void exportOrder(Order order, String fileName){...};

không quan tâm đến thứ tự đến từ đâu - từ DB, từ yêu cầu web, từ kiểm tra đơn vị, v.v. Nó làm cho phương thức này tuyên bố rõ ràng hơn chính xác những gì nó yêu cầu, thay vì lấy DataRow và ghi lại những cột mà nó dự kiến ​​sẽ có và loại nào chúng nên có là. Áp dụng tương tự nếu bạn triển khai nó bằng cách nào đó như thủ tục được lưu trữ - bạn vẫn cần đẩy id bản ghi sang nó, trong khi không cần thiết phải có mặt trong DB.

Việc thực hiện phương pháp này sẽ được thực hiện dựa trên sự trừu tượng hóa Đơn hàng, không dựa trên cách chính xác nó được trình bày trong DB. Hầu hết các hoạt động như vậy mà tôi thực hiện không phụ thuộc vào cách dữ liệu này được lưu trữ. Tôi hiểu rằng một số hoạt động yêu cầu kết hợp với cấu trúc DB cho mục đích hoàn thiện và khả năng mở rộng, theo kinh nghiệm của tôi không có quá nhiều trong số chúng. Theo kinh nghiệm của tôi rất thường xuyên, đủ để biết rằng Person có Chuỗi trả về .getFirstName () và Địa chỉ trả về .getAddress () và địa chỉ có .getZipCode (), v.v. - và không quan tâm bảng nào có liên quan để lưu trữ dữ liệu đó .

Nếu bạn phải xử lý các vấn đề như bạn đã mô tả, như khi cột bổ sung phá vỡ báo cáo về sự hoàn hảo, thì đối với nhiệm vụ của bạn, DB là một phần quan trọng và bạn thực sự nên càng gần nó càng tốt. Trong khi các thực thể có thể cung cấp một số trừu tượng thuận tiện, chúng cũng có thể ẩn một số chi tiết quan trọng.

Khả năng mở rộng là điểm thú vị ở đây - hầu hết các trang web yêu cầu khả năng mở rộng rất lớn (như facebook, livejournal, flickr) có xu hướng sử dụng phương pháp DB-ascetic, khi DB được sử dụng càng hiếm càng tốt và các vấn đề về khả năng mở rộng được giải quyết bằng bộ nhớ cache, đặc biệt là sử dụng RAM. http://highscalability.com/ có một số bài viết thú vị về nó.

Có những lý do tốt khác cho các đối tượng thực thể bên cạnh sự trừu tượng và khớp nối lỏng lẻo. Một trong những điều tôi thích nhất là kiểu gõ mạnh mà bạn không thể có được với DataReader hoặc DataTable. Một lý do khác là khi được thực hiện tốt, các lớp thực thể phù hợp có thể làm cho mã dễ bảo trì hơn bằng cách sử dụng các cấu trúc hạng nhất cho các thuật ngữ dành riêng cho miền mà bất kỳ ai nhìn vào mã đều có thể hiểu thay vì một chuỗi các chuỗi có tên trường được sử dụng để lập chỉ mục một DataRow. Các thủ tục được lưu trữ thực sự trực giao với việc sử dụng ORM do rất nhiều khung ánh xạ cung cấp cho bạn khả năng ánh xạ tới các sprocs.

Tôi sẽ không coi sprocs + datareaders thay thế cho ORM tốt. Với các thủ tục được lưu trữ, bạn vẫn bị ràng buộc bởi và được liên kết chặt chẽ với chữ ký loại của thủ tục, sử dụng một hệ thống loại khác với mã gọi. Các thủ tục được lưu trữ có thể được sửa đổi để bổ sung các tùy chọn bổ sung và thay đổi lược đồ. Một thay thế cho các thủ tục được lưu trữ trong trường hợp lược đồ có thể thay đổi là sử dụng các khung nhìn - bạn có thể ánh xạ các đối tượng thành các khung nhìn và sau đó ánh xạ lại các khung nhìn vào các bảng bên dưới khi bạn thay đổi chúng.

Tôi có thể hiểu ác cảm của bạn với ORM nếu kinh nghiệm của bạn chủ yếu bao gồm Java EE và CSLA. Bạn có thể muốn xem LINQ to SQL, đây là một khung rất nhẹ và chủ yếu là ánh xạ một-một với các bảng cơ sở dữ liệu nhưng thường chỉ cần phần mở rộng nhỏ để chúng là đối tượng kinh doanh toàn diện. LINQ to SQL cũng có thể ánh xạ các đối tượng đầu vào và đầu ra thành các tham số và kết quả của thủ tục được lưu trữ.

Khung thực thể ADO.NET có thêm lợi thế là các bảng cơ sở dữ liệu của bạn có thể được xem như là các lớp thực thể kế thừa lẫn nhau hoặc dưới dạng các cột từ nhiều bảng được tổng hợp thành một thực thể. Nếu bạn cần thay đổi lược đồ, bạn có thể thay đổi ánh xạ từ mô hình khái niệm sang lược đồ lưu trữ mà không thay đổi mã ứng dụng thực tế. Và một lần nữa, các thủ tục lưu trữ có thể được sử dụng ở đây.

Tôi nghĩ rằng nhiều dự án CNTT trong các doanh nghiệp thất bại do mã không rõ ràng hoặc năng suất của nhà phát triển kém (có thể xảy ra, ví dụ, chuyển đổi ngữ cảnh giữa viết sproc và viết ứng dụng) so với các vấn đề về khả năng mở rộng của ứng dụng.

Tôi cũng muốn thêm vào câu trả lời của Dan rằng việc tách cả hai mô hình có thể cho phép ứng dụng của bạn chạy trên các máy chủ cơ sở dữ liệu khác nhau hoặc thậm chí là các mô hình cơ sở dữ liệu.

Điều gì sẽ xảy ra nếu bạn cần mở rộng quy mô ứng dụng của mình bằng cách tải cân bằng nhiều máy chủ web? Bạn có thể cài đặt ứng dụng đầy đủ trên tất cả các máy chủ web, nhưng một giải pháp tốt hơn là để các máy chủ web nói chuyện với một máy chủ ứng dụng.

Nhưng nếu không có bất kỳ đối tượng thực thể nào, họ sẽ không có nhiều điều để nói.

Tôi không nói rằng bạn không nên viết đơn nguyên nếu nó là một ứng dụng đơn giản, nội bộ, ngắn. Nhưng ngay khi nó trở nên phức tạp vừa phải, hoặc nó sẽ kéo dài một khoảng thời gian đáng kể, bạn thực sự cần phải nghĩ về một thiết kế tốt.

Điều này tiết kiệm thời gian khi duy trì nó.

Bằng cách tách logic ứng dụng khỏi logic trình bày và truy cập dữ liệu và bằng cách chuyển DTO giữa chúng, bạn tách chúng ra. Cho phép họ thay đổi độc lập.

Bạn có thể tìm thấy cái này bài đăng trên comp.object thú vị.

Tôi không khẳng định đồng ý hay không đồng ý nhưng điều đó thật thú vị và (tôi nghĩ) có liên quan đến chủ đề này.

Một câu hỏi: Làm thế nào để bạn xử lý các ứng dụng bị ngắt kết nối nếu tất cả logic kinh doanh của bạn bị mắc kẹt trong cơ sở dữ liệu?

Trong loại ứng dụng Doanh nghiệp mà tôi quan tâm, chúng tôi phải xử lý nhiều trang web, một số trong số chúng phải có thể hoạt động ở trạng thái ngắt kết nối.
Nếu logic kinh doanh của bạn được gói gọn trong một lớp Miền đơn giản để kết hợp vào các loại ứng dụng khác nhau - như mộtdll - thì tôi có thể xây dựng các ứng dụng nhận thức được các quy tắc kinh doanh và khi cần thiết, có thể áp dụng chúng cục bộ.

Để giữ lớp Miền trong các thủ tục được lưu trữ trên cơ sở dữ liệu, bạn phải gắn bó với một loại ứng dụng duy nhất cần một đường ngắm vĩnh viễn vào cơ sở dữ liệu.

Nó ổn đối với một loại môi trường nhất định, nhưng chắc chắn nó không bao gồm toàn bộ các ứng dụng Enterprise .

@jdecuyper, một câu châm ngôn tôi thường nhắc lại với bản thân mình là "nếu logic kinh doanh của bạn không có trong cơ sở dữ liệu của bạn, thì đó chỉ là một đề xuất". Tôi nghĩ Paul Nielson đã nói điều đó trong một trong những cuốn sách của mình. Các lớp ứng dụng và giao diện người dùng đến và đi, nhưng dữ liệu thường tồn tại trong một thời gian rất dài.

Làm thế nào để tôi tránh các đối tượng thực thể? Thủ tục lưu trữ là chủ yếu. Tôi cũng tự do thừa nhận rằng logic kinh doanh có xu hướng tiếp cận qua tất cả các lớp trong một ứng dụng cho dù bạn có ý định hay không. Một số lượng nhất định của khớp nối là cố hữu và không thể tránh khỏi.

Gần đây tôi đã suy nghĩ về điều này rất nhiều; Tôi đã là một người sử dụng CSLA rất lâu và tôi thích sự thuần khiết khi nói rằng "tất cả logic kinh doanh của bạn (hoặc ít nhất là càng nhiều càng tốt) được gói gọn trong các thực thể kinh doanh".

Tôi đã thấy mô hình thực thể kinh doanh cung cấp rất nhiều giá trị trong trường hợp thiết kế cơ sở dữ liệu khác với cách bạn làm việc với dữ liệu, đó là trường hợp trong rất nhiều phần mềm kinh doanh.

Ví dụ: ý tưởng về "khách hàng" có thể bao gồm một bản ghi chính trong bảng Khách hàng, kết hợp với tất cả các đơn đặt hàng mà khách hàng đã đặt, cũng như tất cả nhân viên của khách hàng và thông tin liên hệ của họ và một số thuộc tính của một khách hàng và con của nó có thể được xác định từ các bảng tra cứu. Thật tuyệt vời từ quan điểm phát triển để có thể làm việc với Khách hàng như một thực thể duy nhất, vì từ góc độ kinh doanh, khái niệm Khách hàng chứa tất cả những điều này và các mối quan hệ có thể hoặc không thể được thực thi trong cơ sở dữ liệu.

Mặc dù tôi đánh giá cao câu nói "nếu quy tắc kinh doanh của bạn không có trong cơ sở dữ liệu của bạn, thì đó chỉ là một gợi ý", tôi cũng tin rằng bạn không nên thiết kế cơ sở dữ liệu để thực thi các quy tắc kinh doanh, bạn nên thiết kế nó để hiệu quả, nhanh chóng và bình thường hóa .

Điều đó nói rằng, như những người khác đã lưu ý ở trên, không có "thiết kế hoàn hảo", công cụ phải phù hợp với công việc. Nhưng sử dụng các thực thể kinh doanh thực sự có thể giúp bảo trì và năng suất, vì bạn biết phải sửa đổi logic kinh doanh ở đâu và các đối tượng có thể mô hình hóa các khái niệm trong thế giới thực theo cách trực quan.

Eric

Không ai ngăn bạn chọn khuôn khổ / cách tiếp cận mà bạn muốn. Nếu bạn định đi theo con đường "hướng dữ liệu / lưu trữ thủ tục được lưu trữ", thì bằng mọi cách, hãy đi cho nó! Đặc biệt là nếu nó thực sự, thực sự giúp bạn cung cấp các ứng dụng của bạn đúng thời gian và đúng thời gian.

Hãy cẩn thận (đó là một câu hỏi thường gặp), TẤT CẢ các quy tắc kinh doanh của bạn nên có trong các thủ tục được lưu trữ và ứng dụng của bạn không gì khác hơn là một khách hàng mỏng.

Điều đó đang được nói, các quy tắc tương tự được áp dụng nếu bạn thực hiện ứng dụng của mình trong OOP: nhất quán. Thực hiện theo nguyên lý của OOP và đó bao gồm việc tạo ra thực thể đối tượng để đại diện cho mô hình tên miền của bạn.

Quy tắc thực sự duy nhất ở đây là tính nhất quán từ . Không ai ngăn cản bạn đi DB-centric. Không ai ngăn cản bạn thực hiện các chương trình có cấu trúc (hay còn gọi là chức năng / thủ tục) của trường học cũ. Quỷ quái, không ai ngăn cản ai làm mã theo kiểu COBOL. NHƯNG một ứng dụng phải rất, rất nhất quán một khi đi xuống con đường này, nếu nó muốn đạt được bất kỳ mức độ thành công nào.

Tôi thực sự không chắc chắn những gì bạn xem là "Ứng dụng doanh nghiệp". Nhưng tôi đang có ấn tượng rằng bạn đang xác định nó là Ứng dụng nội bộ nơi RDBMS sẽ được thiết lập và hệ thống sẽ không phải tương thích với bất kỳ hệ thống nào khác dù là nội bộ hay bên ngoài.

Nhưng điều gì sẽ xảy ra nếu bạn có một cơ sở dữ liệu với 100 bảng tương đương với 4 Quy trình được lưu trữ cho mỗi bảng chỉ dành cho các hoạt động CRUD cơ bản, đó là 400 quy trình được lưu trữ cần được duy trì và không được gõ mạnh nên dễ bị lỗi chính tả cũng không thể được Kiểm tra lỗi chính tả . Điều gì xảy ra khi bạn nhận được một CTO mới là Nhà truyền giáo nguồn mở và muốn thay đổi RDBMS từ SQL Server thành MySql?

Ngày nay, rất nhiều phần mềm cho dù Ứng dụng hoặc Sản phẩm dành cho Doanh nghiệp đang sử dụng SOA và có một số yêu cầu để hiển thị Dịch vụ Web, ít nhất là phần mềm tôi đang và đã tham gia. Sử dụng phương pháp của bạn, bạn sẽ kết thúc việc hiển thị DataTable hoặc DataRows được tuần tự hóa. Bây giờ điều này có thể được coi là chấp nhận được nếu Máy khách được đảm bảo là .NET và trên mạng nội bộ. Nhưng khi Khách hàng không biết thì bạn nên cố gắng Thiết kế API trực quan và trong hầu hết các trường hợp, bạn sẽ không muốn hiển thị lược đồ Cơ sở dữ liệu đầy đủ. Tôi chắc chắn sẽ không muốn giải thích cho nhà phát triển Java về DataTable là gì và cách sử dụng nó. Ngoài ra còn có sự xem xét của Bandwith và kích thước tải trọng và DataTables được tuần tự hóa, DataSets rất nặng.

Không có viên đạn bạc nào với thiết kế phần mềm và nó thực sự phụ thuộc vào mức độ ưu tiên, đối với tôi, đó là mã Đơn vị có thể kiểm tra và các thành phần được ghép lỏng lẻo có thể dễ dàng tiêu thụ cho bất kỳ khách hàng nào.

chỉ 2 xu của tôi

Tôi muốn đưa ra một góc độ khác cho vấn đề khoảng cách giữa OO và RDB: history.

Bất kỳ phần mềm nào cũng có một mô hình thực tế ở một mức độ nào đó là sự trừu tượng của thực tế. Không có chương trình máy tính nào có thể nắm bắt được tất cả sự phức tạp của thực tế và các chương trình được viết chỉ để giải quyết một loạt các vấn đề từ thực tế. Do đó, bất kỳ mô hình phần mềm là giảm thực tế. Đôi khi mô hình phần mềm buộc thực tế phải giảm bớt chính nó. Giống như khi bạn muốn công ty cho thuê xe đặt trước bất kỳ chiếc xe nào cho bạn miễn là nó có màu xanh và có hợp kim, nhưng nhà điều hành không thể tuân thủ vì yêu cầu của bạn sẽ không phù hợp với máy tính.

RDB xuất phát từ một truyền thống rất lâu đời về việc đưa thông tin vào các bảng, được gọi là kế toán. Kế toán được thực hiện trên giấy, sau đó trên thẻ đục lỗ, sau đó trong máy tính. Nhưng kế toán đã là một thực tế giảm. Kế toán đã buộc mọi người phải theo hệ thống của nó quá lâu để nó trở thành hiện thực được chấp nhận. Đó là lý do tại sao việc tạo ra phần mềm máy tính cho kế toán tương đối dễ dàng, kế toán đã có mô hình thông tin của nó, rất lâu trước khi máy tính xuất hiện.

Do tầm quan trọng của hệ thống kế toán tốt và sự chấp nhận bạn nhận được từ bất kỳ nhà quản lý doanh nghiệp nào, các hệ thống này đã trở nên rất tiên tiến. Các nền tảng cơ sở dữ liệu bây giờ rất vững chắc và không ai ngần ngại về việc giữ dữ liệu quan trọng trong một cái gì đó rất đáng tin cậy.

Tôi đoán rằng OO phải xuất hiện khi mọi người thấy rằng các khía cạnh khác của thực tế khó mô hình hóa hơn kế toán (vốn đã là một mô hình). OO đã trở thành một ý tưởng rất thành công, nhưng sự kiên trì của dữ liệu OO tương đối kém phát triển. RDB / Kế toán đã có những chiến thắng dễ dàng, nhưng OO là một lĩnh vực lớn hơn nhiều (về cơ bản mọi thứ không phải là kế toán).

Vì vậy, nhiều người trong chúng ta đã muốn sử dụng OO nhưng chúng tôi vẫn muốn lưu trữ an toàn dữ liệu của mình. Điều gì có thể an toàn hơn là lưu trữ dữ liệu của chúng tôi giống như hệ thống kế toán quý giá? Đó là một triển vọng hấp dẫn, nhưng tất cả chúng ta đều gặp phải những cạm bẫy giống nhau. Rất ít người gặp khó khăn khi nghĩ đến sự kiên trì của OO so với những nỗ lực to lớn của ngành RDB, người có lợi ích từ truyền thống và vị trí của kế toán.

Prevayler và db4o là một số gợi ý, tôi chắc chắn có những đề xuất khác mà tôi chưa từng nghe đến, nhưng dường như không có ai nhận được một nửa báo chí như, nói, ngủ đông.

Lưu trữ các đối tượng của bạn trong các tệp cũ tốt dường như thậm chí không được coi trọng đối với các ứng dụng nhiều người dùng và đặc biệt là các ứng dụng web.

Trong cuộc đấu tranh hàng ngày của tôi để thu hẹp khoảng cách giữa OO và RDB, tôi sử dụng OO càng nhiều càng tốt nhưng cố gắng giữ sự kế thừa ở mức tối thiểu. Tôi không thường xuyên sử dụng SP. Tôi sẽ chỉ sử dụng các công cụ truy vấn nâng cao trong các khía cạnh giống như kế toán.

Tôi sẽ rất vui khi ngạc nhiên khi sự ngăn chặn được đóng lại. Tôi nghĩ rằng giải pháp sẽ đến khi Oracle ra mắt một cái gì đó như "Cơ sở đối tượng Oracle". Để thực sự bắt kịp, nó sẽ phải có một cái tên trấn an.

Không có nhiều thời gian vào lúc này, nhưng ngay trên đỉnh đầu của tôi ...

Mô hình thực thể cho phép bạn cung cấp một giao diện nhất quán cho cơ sở dữ liệu (và các hệ thống có thể khác) thậm chí vượt xa những gì giao diện thủ tục được lưu trữ có thể làm. Bằng cách sử dụng các mô hình kinh doanh toàn doanh nghiệp, bạn có thể đảm bảo rằng tất cả các ứng dụng ảnh hưởng đến dữ liệu một cách nhất quán, đó là một điều RẤT quan trọng. Nếu không, bạn kết thúc với dữ liệu xấu, đó chỉ là xấu xa.

Nếu bạn chỉ có một ứng dụng thì bạn không thực sự có hệ thống "doanh nghiệp", bất kể ứng dụng đó hoặc dữ liệu của bạn lớn đến mức nào. Trong trường hợp đó, bạn có thể sử dụng một cách tiếp cận tương tự như những gì bạn nói về. Chỉ cần lưu ý về công việc sẽ cần nếu bạn quyết định phát triển hệ thống của mình trong tương lai.

Dưới đây là một số điều mà bạn nên ghi nhớ (IMO):

1. Mã SQL được tạo là xấu (ngoại lệ để làm theo). Xin lỗi, tôi biết rằng nhiều người nghĩ rằng đó là một trình tiết kiệm thời gian khổng lồ, nhưng tôi chưa bao giờ tìm thấy một hệ thống có thể tạo mã hiệu quả hơn những gì tôi có thể viết và thường thì mã này thật kinh khủng. Cuối cùng, bạn cũng thường tạo ra một tấn mã SQL không bao giờ được sử dụng. Ngoại lệ ở đây là các mẫu rất đơn giản, như có thể bảng tra cứu. Rất nhiều người được mang đi trên đó mặc dù.
2. Các thực thể <> Bảng (hoặc thậm chí các thực thể mô hình dữ liệu logic nhất thiết). Một mô hình dữ liệu thường có các quy tắc dữ liệu nên được thực thi càng gần cơ sở dữ liệu càng tốt, có thể bao gồm các quy tắc xung quanh cách các hàng của bảng liên quan đến nhau hoặc các quy tắc tương tự khác quá phức tạp đối với RI khai báo. Chúng nên được xử lý trong các thủ tục lưu trữ. Nếu tất cả các thủ tục được lưu trữ của bạn là các procs CRUD đơn giản, bạn không thể làm điều đó. Trên hết, mô hình CRUD thường tạo ra các vấn đề về hiệu suất vì nó không giảm thiểu các chuyến đi khứ hồi qua mạng đến cơ sở dữ liệu. Đó thường là nút cổ chai lớn nhất trong một ứng dụng doanh nghiệp.

Đôi khi, ứng dụng và lớp dữ liệu của bạn không được kết hợp chặt chẽ. Ví dụ: bạn có thể có một ứng dụng thanh toán qua điện thoại. Sau đó, bạn tạo một ứng dụng riêng biệt theo dõi việc sử dụng điện thoại để a) quảng cáo tốt hơn cho bạn b) tối ưu hóa gói điện thoại của bạn.

Các ứng dụng này có mối quan tâm và yêu cầu dữ liệu khác nhau (ngay cả dữ liệu được đưa ra từ cùng một cơ sở dữ liệu), chúng sẽ điều khiển các thiết kế khác nhau. Cơ sở mã của bạn có thể kết thúc một mớ hỗn độn tuyệt đối (trong cả hai ứng dụng) và một cơn ác mộng phải duy trì nếu bạn để cơ sở dữ liệu điều khiển mã.

Các ứng dụng có logic miền tách biệt với logic lưu trữ dữ liệu có thể thích ứng với mọi loại nguồn dữ liệu (cơ sở dữ liệu hoặc cách khác) hoặc ứng dụng UI (web hoặc windows (hoặc linux, v.v.)).

Bạn bị mắc kẹt khá nhiều trong cơ sở dữ liệu của mình, điều đó không tệ nếu bạn cùng với một công ty hài lòng với hệ thống cơ sở dữ liệu hiện tại mà bạn sử dụng. Tuy nhiên, vì cơ sở dữ liệu phát triển thêm giờ nên có thể có một hệ thống cơ sở dữ liệu mới thực sự gọn gàng và mới mà công ty bạn muốn sử dụng. Điều gì sẽ xảy ra nếu họ muốn chuyển sang phương thức truy cập dữ liệu dịch vụ web (như kiến ​​trúc Định hướng dịch vụ đôi khi). Bạn có thể phải chuyển các thủ tục được lưu trữ của bạn ở khắp mọi nơi.

Ngoài ra logic tên miền trừu tượng hóa UI, điều này có thể quan trọng hơn trong các hệ thống phức tạp lớn đã từng phát triển UI (đặc biệt là khi chúng liên tục tìm kiếm thêm khách hàng).

Ngoài ra, trong khi tôi đồng ý rằng không có câu trả lời dứt khoát cho câu hỏi về các thủ tục được lưu trữ so với logic miền. Tôi đang ở trong trại logic miền (và tôi nghĩ rằng họ đang chiến thắng theo thời gian), bởi vì tôi tin rằng các thủ tục lưu trữ phức tạp khó duy trì hơn logic logic phức tạp. Nhưng đó là một cuộc tranh luận hoàn toàn khác

Tôi nghĩ rằng bạn chỉ quen viết một loại ứng dụng cụ thể và giải quyết một loại vấn đề nhất định. Bạn dường như đang tấn công điều này từ quan điểm "cơ sở dữ liệu đầu tiên". Có rất nhiều nhà phát triển ngoài kia, nơi dữ liệu được duy trì cho DB nhưng hiệu suất không phải là ưu tiên hàng đầu. Trong rất nhiều trường hợp, việc đặt một sự trừu tượng hóa trên lớp kiên trì sẽ đơn giản hóa mã rất nhiều và chi phí hiệu năng là một vấn đề không phải là vấn đề.

Dù bạn đang làm gì, đó không phải là OOP. Điều đó không sai, nó không phải là OOP và không có ý nghĩa gì khi áp dụng các giải pháp của bạn cho mọi vấn đề ngoài kia.

Câu hỏi thú vị. Một vài suy nghĩ:

1. Làm thế nào bạn sẽ kiểm tra đơn vị nếu tất cả logic kinh doanh của bạn có trong cơ sở dữ liệu của bạn?
2. Sẽ không thay đổi cấu trúc cơ sở dữ liệu của bạn, cụ thể là những trang ảnh hưởng đến một số trang trong ứng dụng của bạn, có phải là một rắc rối lớn để thay đổi trong toàn bộ ứng dụng không?

Câu hỏi hay!

Một cách tiếp cận tôi thích là tạo một đối tượng lặp / trình tạo phát ra các thể hiện của các đối tượng có liên quan đến một bối cảnh cụ thể. Thông thường đối tượng này bao bọc một số công cụ truy cập cơ sở dữ liệu cơ bản, nhưng tôi không cần biết điều đó khi sử dụng nó.

Ví dụ,

Một đối tượng answerIterator tạo ra các đối tượng answerIterator.Answer. Trong phần mềm, nó lặp đi lặp lại qua Câu lệnh SQL để tìm nạp tất cả các câu trả lời và một câu lệnh SQL khác để tìm nạp tất cả các nhận xét liên quan. Nhưng khi sử dụng iterator tôi chỉ sử dụng đối tượng Trả lời có các thuộc tính tối thiểu cho bối cảnh này. Với một chút mã bộ xương, điều này trở nên gần như không đáng để làm.

Tôi đã thấy rằng điều này hoạt động tốt khi tôi có một bộ dữ liệu khổng lồ để làm việc và khi được thực hiện đúng, nó mang lại cho tôi các đối tượng nhỏ, thoáng qua, tương đối dễ kiểm tra.

Về cơ bản, nó là một lớp veneer mỏng trên các công cụ truy cập cơ sở dữ liệu, nhưng nó vẫn mang lại cho tôi sự linh hoạt trong việc trừu tượng hóa nó khi tôi cần.

Các đối tượng trong ứng dụng của tôi có xu hướng liên kết một-một với cơ sở dữ liệu, nhưng tôi thấy việc sử dụng Linq To Sql chứ không phải sprocs giúp viết các truy vấn phức tạp dễ dàng hơn nhiều, đặc biệt là có thể xây dựng chúng bằng cách sử dụng thực thi bị trì hoãn. ví dụ: từ r trong Images.User.Ratings, v.v ... Điều này giúp tôi cố gắng tìm ra một số câu lệnh nối trong sql và việc Skip & Take để phân trang cũng đơn giản hóa mã thay vì phải nhúng mã row_number & 'over'.

Tại sao dừng lại ở các đối tượng thực thể? Nếu bạn không thấy giá trị với các đối tượng thực thể trong ứng dụng cấp doanh nghiệp, thì bạn chỉ cần truy cập dữ liệu của mình bằng ngôn ngữ thủ tục / chức năng thuần túy và kết nối nó với UI. Tại sao không cắt bỏ tất cả các "lông tơ" OO?