Việc viết Lớp truy cập dữ liệu / Ánh xạ dữ liệu của riêng bạn có phải là một ý tưởng hay không?

Chúng tôi hiện đang ở trong một tình huống mà chúng tôi có sự lựa chọn giữa việc sử dụng một trình ánh xạ quan hệ đối tượng bên ngoài hoặc tự lăn

Chúng tôi có một ứng dụng kế thừa (ASP.NET + SQL Server) trong đó lớp dữ liệu & lớp nghiệp vụ không may bị trộn lẫn với nhau. Hệ thống không đặc biệt phức tạp về khả năng truy cập dữ liệu. Nó đọc dữ liệu từ một nhóm lớn (35-40) các bảng liên quan đến nhau, thao tác nó trong bộ nhớ và lưu lại vào một số bảng khác ở định dạng tóm tắt. Bây giờ chúng tôi có cơ hội để tái cấu trúc và đang xem xét các công nghệ ứng cử viên để sử dụng để phân tách & cấu trúc đúng cách Truy cập dữ liệu của chúng tôi.

Bất cứ công nghệ nào chúng tôi quyết định, chúng tôi muốn:

• có các đối tượng POCO trong Mô hình miền của chúng tôi không biết gì về tính bền bỉ
• có một lớp trừu tượng để cho phép chúng tôi Đơn vị Kiểm tra các đối tượng mô hình miền của chúng tôi chống lại một nguồn dữ liệu cơ bản được mô phỏng

Rõ ràng có rất nhiều thứ trên đó về các Mẫu & Khung, v.v.

Cá nhân tôi đang thúc đẩy việc sử dụng EF kết hợp với Trình tạo kho lưu trữ có thể kiểm tra đơn vị ADO.NET / Trình tạo thực thể POCO . Nó đáp ứng tất cả các yêu cầu của chúng tôi, có thể dễ dàng được gói trong Mẫu Repo / UnitOfWork và Cấu trúc DB của chúng tôi hoàn toàn trưởng thành (đã trải qua một bộ tái cấu trúc) để chúng tôi sẽ không thực hiện các thay đổi hàng ngày cho mô hình.

Tuy nhiên, những người khác trong nhóm đang đề xuất kiến ​​trúc / cán DAL của chúng ta hoàn toàn từ đầu. (Trình tạo dữ liệu tùy chỉnh, DataContexts, Kho lưu trữ, Giao diện ở mọi nơi, Sự phụ thuộc quá mức cần thiết để tạo các đối tượng cụ thể, Dịch thuật truy vấn LINQ-Under-Under tùy chỉnh, Triển khai bộ đệm tùy chỉnh, Triển khai FetchPlan tùy chỉnh ...) tôi như điên

Một số đối số được đưa ra là "Ít nhất chúng ta sẽ kiểm soát mã của chính mình" hoặc "Ôi tôi đã sử dụng L2S ​​/ EF trong một dự án trước đó và nó không có gì ngoài đau đầu". (Mặc dù tôi đã sử dụng cả trong Sản xuất trước đây và thấy bất kỳ vấn đề nào xảy ra rất ít và rất dễ quản lý)

Vì vậy, bất kỳ nhà phát triển / kiến ​​trúc sư giàu kinh nghiệm nào của bạn ngoài kia có bất kỳ lời khôn ngoan nào có thể giúp tôi điều khiển sản phẩm này khỏi những gì dường như tôi sẽ là một thảm họa hoàn toàn. Tôi không thể không nghĩ rằng bất kỳ lợi ích nào có được khi tránh các vấn đề của EF, sẽ bị mất nhanh chóng bằng cách cố gắng phát minh lại bánh xe.

Cả hai đối số chống lại các ORM hiện tại đều không hợp lệ:

"Ít nhất chúng ta sẽ kiểm soát mã của chính mình"

Tại sao không viết ngôn ngữ của riêng bạn? Khuôn khổ của riêng bạn? Hệ điều hành của riêng bạn? Và để chắc chắn rằng bạn đang kiểm soát mọi thứ, đó cũng là một ý tưởng tốt để tạo phần cứng của riêng bạn.

"Ồ tôi đã sử dụng L2S ​​/ EF trong một dự án trước đó và nó không có gì ngoài đau đầu"

EF đủ trưởng thành và được nhiều người sử dụng thành công. Điều đó có nghĩa là một người tuyên bố rằng EF không là gì ngoài đau đầu có lẽ nên bắt đầu học cách sử dụng EF đúng cách.

Vì vậy, bạn có phải viết ORM của riêng bạn?

Tôi sẽ không đề nghị điều đó. Đã có các ORM cấp độ chuyên nghiệp, điều đó có nghĩa là bạn phải tự viết chỉ khi:

• Bạn có một bối cảnh chính xác nơi tất cả các ORM hiện tại không thể phù hợp vì một số lý do,
• Bạn chắc chắn rằng chi phí tạo và sử dụng ORM của riêng bạn thay vì học một cái hiện có thấp hơn nhiều. Điều này bao gồm chi phí hỗ trợ trong tương lai, bao gồm bởi một nhóm các nhà phát triển khác, những người sẽ phải đọc hàng trăm trang tài liệu kỹ thuật của bạn để hiểu cách làm việc với ORM của bạn.

Tất nhiên, không có gì cấm bạn viết ORM của riêng bạn chỉ vì tò mò, để tìm hiểu mọi thứ. Nhưng bạn không nên làm điều đó trong một dự án thương mại.

Xem thêm từ 2 đến 3 câu trả lời của tôi cho câu hỏi Phát minh lại bánh xe và KHÔNG hối tiếc. Bạn có thể thấy rằng những lý do khác nhau để phát minh lại bánh xe không áp dụng ở đây.

Sử dụng Entity Framework cho tất cả các công cụ CRUD thông thường (80 đến 95 phần trăm mã) và sử dụng mã truy cập dữ liệu tùy chỉnh cho bất kỳ mã nào còn lại cần được tối ưu hóa. Điều này sẽ thỏa mãn mối quan tâm của những người tranh luận rằng bạn không có đủ quyền kiểm soát.

Đó là một ý tưởng tốt nếu và chỉ khi bạn có thể (ít nhất là hợp lý) chắc chắn rằng bạn sẽ tiết kiệm ít nhất là nhiều thời gian / công sức bằng cách viết mã của riêng bạn khi cần tạo mã đó ngay từ đầu. Tùy thuộc vào tình huống, làm như vậy cũng có thể ảnh hưởng đến lịch trình của bạn và bạn cũng sẽ phải tính đến điều đó. Bạn cũng phải yếu tố bảo trì dài hạn vào phương trình. Nếu bạn cuộn ORM của riêng mình, bạn sẽ cần duy trì nó mãi mãi (hoặc ít nhất là miễn là bạn sử dụng nó).

Điểm mấu chốt là nó có thể có ý nghĩa, trong điều kiện phù hợp. Những điều kiện này thường bao gồm:

1. Dự án bạn đang thực hiện khá lớn, do đó chi phí được khấu hao theo số lượng lớn sử dụng.
2. Việc sử dụng dữ liệu của bạn đủ khác thường khi các thư viện hiện tại (và như vậy) hoạt động khá kém cho mục đích của bạn.

Có nguy cơ nêu rõ, hai điều này có liên quan nghịch đảo - nếu bạn đang làm việc trong một dự án thực sự vĩ đại, thì ngay cả một khoản tiết kiệm nhỏ ở mỗi lần sử dụng cũng có thể đủ để chứng minh sự phát triển. Ngược lại, nếu nhu cầu của bạn thực sự khác thường, vì vậy bạn đạt được rất nhiều sau mỗi lần sử dụng, công việc có thể được biện minh ngay cả trong một dự án khá nhỏ.

Ít nhất là dựa trên mô tả của bạn, tuy nhiên, không thực sự áp dụng trong trường hợp của bạn. Có lẽ một (hoặc thậm chí cả hai) được áp dụng cho việc sử dụng EF trước đây của đồng nghiệp của bạn, hoặc có lẽ anh ta chỉ định kiến ​​- Tôi không nghĩ bạn đã cung cấp cho chúng tôi đủ thông tin để đoán xem (mặc dù công bằng, tôi nên thêm rằng tôi ' d đoán đó là vì anh ta đã không nói với bạn gần như đủ để đoán).

Nếu tôi chịu trách nhiệm về tình huống này, tôi nghĩ rằng tôi và bạn đồng nghiệp của bạn mỗi người viết một loại giấy vị trí - một danh sách các điểm mạnh và điểm yếu bạn thấy với mỗi phương pháp, cùng với bằng chứng thực tế để hỗ trợ cho từng khẳng định / yêu cầu /bất cứ điều gì. Toàn bộ đội sau đó sẽ nhận được (nghĩa là sẽ được yêu cầu) phê bình từng bài. Điểm chính trong bài phê bình của họ là đánh giá từng điểm trên hai thang điểm:

1. mức độ mà điểm có vẻ chính xác, được hỗ trợ tốt bởi các sự kiện, v.v., và
2. mức độ mà điểm xuất hiện để áp dụng cho dự án trong tầm tay.

Sau đó, tôi sẽ đánh giá các bài báo và các phê bình để đưa ra quyết định (mặc dù hoàn toàn trung thực, có thể khó nói tôi đã sử dụng chúng bao nhiêu để đưa ra quyết định và tôi đã sử dụng chúng bao nhiêu để đưa ra quyết định Tôi đã thực hiện - Tôi biết có lẽ tôi không nên thừa nhận điều đó, nhưng thực tế là tôi cũng là con người ...)

Chỉnh sửa:

Nếu tôi muốn đặc biệt khó chịu (hoặc "giáo dục" - khó có thể nhận ra sự khác biệt trong trường hợp này) thì mỗi bạn sẽ cố gắng phát triển một ước tính về nỗ lực phát triển tổng thể cả bằng cách sử dụng ORM / DAL hiện có và phát triển của riêng bạn Mặc dù đó chỉ là dự đoán, nhưng phỏng đoán ngay lập tức của tôi là hầu hết những người có kế hoạch lớn sẽ tự mình thực hiện các ước tính của mình - đến lúc họ đưa ra một ước tính về nỗ lực tổng thể thậm chí đã kết thúc từ xa (và thực tế), họ sẽ nhận ra rằng không có cách nào họ thậm chí có thể tiến gần đến việc cạnh tranh với việc sử dụng mã hiện có. Đồng thời, nó '

Chỉnh sửa 2: (sắp xếp theo đề xuất của @ CmdKey): Mặc dù không được đề cập rõ ràng, tôi cho rằng một ước tính sẽ hoàn toàn bao gồm đánh giá rủi ro. Cụ thể, ước tính thời gian thường bao gồm các số kiểu PERT:

1. Ước tính trường hợp tốt nhất về tốc độ nhanh nhất có thể được thực hiện nếu mọi thứ đều ổn.
2. Ước tính "bình thường" - bạn dự kiến ​​sẽ mất bao lâu.
3. Ước tính trường hợp xấu nhất là lâu nhất có thể xảy ra nếu mọi thứ đều sai.

Tất nhiên, ước tính tốt nhất và trường hợp xấu nhất thường không bao gồm những thứ như can thiệp trực tiếp từ thần thánh, nhưng nên bao gồm bất cứ điều gì ngắn gọn.

Thông thường không bao giờ là một ý tưởng tốt để phát minh lại bánh xe, và làm như vậy thường là một dấu hiệu cho sự thiếu hiểu biết về kỹ thuật ("Tôi không biết gì khác và không muốn học") hoặc kiêu ngạo ("X là ngu ngốc, tôi có thể viết công cụ của riêng tôi trong hai tuần! "); Có những công cụ trưởng thành có thể làm mọi thứ tốt hơn rất nhiều so với những gì một số nhà phát triển trung bình có thể hack cùng nhau trong một vài tuần.

Tuy nhiên, điều đó nói rằng, có những lúc bạn không thể tin cậy một ứng dụng kế thừa xung quanh một giải pháp hiện có (bất kể nó linh hoạt đến mức nào) mà không có quá nhiều công việc; trong trường hợp như thế này không phải là ý tưởng "tốt", nhưng là ý tưởng tốt hơn so với các lựa chọn thay thế (nghĩa là để nguyên như vậy hoặc viết lại một nửa trong số đó để có thể sử dụng lớp bên thứ ba) để bạn có ít lựa chọn.

Tôi đã tham gia một dự án đã từ chối các công cụ Java ORM hiện có để tự viết, do một số tính năng "quan trọng" không có trong Hibernate. Đây là một sai lầm hàng triệu đô la và chi phí đang tăng lên hàng ngày. Họ vẫn chưa có sự hỗ trợ đầy đủ cho các mối quan hệ đối tượng. Vì vậy, ngoài tất cả thời gian dành cho việc tạo và duy trì khung, họ đang dành hàng giờ để viết mã có thể được viết trong vài phút bằng Hibernate hoặc trong nhiều trường hợp hoàn toàn không cần phải viết.

Các khuôn khổ hiện tại là sản phẩm của hàng chục năm nỗ lực. Thật ngớ ngẩn khi tưởng tượng rằng một đội duy nhất có thể đến bất cứ nơi nào gần trong một vài tuần.

Mã bạn phải viết là mã bạn phải duy trì. Thời gian dành cho việc duy trì mã ORM là thời gian dành cho việc không duy trì ứng dụng. Trừ khi ORM mang lại cho bạn một số lợi thế chiến lược, thì đó không phải là thứ sẽ tạo ra tiền cho doanh nghiệp, vì vậy đó là chi phí hoàn toàn. Công ty của bạn sẽ chi tiền cho chi phí hoạt động hoặc nâng cao một sản phẩm kiếm tiền? Nếu đây là một ứng dụng nội bộ thì đây có thể không phải là vấn đề, nhưng bạn vẫn đang tăng số lượng mã cần viết, kiểm tra và ghi lại.

Tôi muốn nói rằng việc tung ra ORM của riêng bạn là một ý tưởng BAD - trừ khi bạn có một lý do rất, rất thần thánh để làm điều đó (btw. Những người bạn đã trích dẫn không đủ tốt :)

Tôi đã phạm sai lầm một lần khi người khác thuyết phục tôi không sử dụng ORM và tôi có thể nói với bạn rằng việc viết tất cả DAL thực sự làm chúng tôi chậm lại và thay vì thực hiện các tính năng quan trọng cho việc kinh doanh, chúng tôi đã dành thời gian cho DAL (công việc này còn nhiều hơn hơn vẻ ngoài của nó)

EF mới có vẻ khá tốt, nhưng nếu bạn muốn kiểm soát nhiều hơn - tôi đã sử dụng micro ORM / s như: Drapper http://code.google.com.vn/p/dapper-dot-net/ hoặc PetaPOCO http : //www.toptensoftware.com/petapoco/

Bạn cũng có thể trộn và kết hợp - sử dụng EF cho số lượng lớn nội dung và Drapper để điều chỉnh tốt.

Dù sao đó chỉ là 2c của tôi;)