API - CFC so với cfinclude

Question

Vì vậy, công ty tôi làm việc có một cách tiếp cận khá tổ chức khi nói đến trang web của chúng tôi. Tất cả các kịch bản của chúng tôi là thủ tục với các câu lệnh được đưa vào bên trong. Tôi đã muốn tổ chức này thành một API nội bộ mà các nhà phát triển web khác sẽ sử dụng để làm bất cứ điều gì (bởi vì thực hiện một thay đổi có tôi đi qua và định vị MỌI ví dụ khác mà thay đổi cần phải được cập nhật).

Cuối cùng tôi có một ví dụ trực tiếp và cho biết ông chủ. Nó theo những gì tôi giả định là phương pháp bình thường (từ googling của tôi). Tầng dịch vụ> Cổng & DAO> Đậu, với một số nhà máy để giúp tạo đối tượng. Nó hoạt động tốt và thực hiện chính xác những gì tôi đã muốn nó thực hiện. Anh ấy ấn tượng với nó và đồng ý rằng chúng tôi cần phải viết mã của chúng tôi và tổ chức tốt hơn nhưng không thấy lợi thế của việc sử dụng phương thức này đối với các cuộc gọi API hướng đối tượng đến một danh sách lớn các cfincludes để thực hiện điều tương tự. Về bản chất, từ cách anh ta giải thích các cfincludes, nó sẽ hoạt động giống như một cuộc gọi phương thức.

Anh ấy được hỏi về ưu điểm của cách tiếp cận của tôi so với cfinclude này và cho cuộc sống của tôi Tôi không thể tìm thấy bất kỳ lợi thế rõ ràng nào khác ngoài nhóm các dữ liệu tương tự trong cùng một đối tượng. Có điều gì khác hay đúng hơn là có lẽ sẽ thuận lợi để đi với phương pháp cfinclude?

Answer 1

Khả năng đọc, bảo trì và tuân thủ các mô hình hướng đối tượng đã được chứng minh sẽ là các khía cạnh quan trọng nhất của việc xây dựng ứng dụng Coldfusion sử dụng một lớp dịch vụ thực sự của CFC/đối tượng, thay vì vô số cfincludes. tốt nhất, và có thể gây ra những cơn ác mộng về thu gom rác ở mức tồi tệ nhất.

Độ khó

Hãy nói rằng bạn có một cfinclude gọi _queries.cfm, trong đó bao gồm tất cả các cuộc gọi cho các ứng dụng của bạn. Sau đó, ở đầu trang nhân viên của bạn, ngay trước khi bạn xuất tất cả nhân viên, bạn thực hiện việc này:

<cfinclude template="_queries.cfm" /> 

<cfoutput query="employeeQry"> 

Nhân viên ở đâu đến? Đây có phải là một trong các truy vấn trong mẫu đó không? Nó làm gì? Tôi có cần đưa mẫu đó vào khi tôi chỉ muốn nhân viên không? Điều gì sẽ xảy ra nếu nó có tất cả các truy vấn trong trang web ... tất cả chúng có cần phải được bao gồm mỗi lần?

Tại sao không một chút gì đó dễ đọc hơn, như thế này:

<cfset employeeQry = request.model.queries.getEmployees() /> 

<cfoutput query="employeeQry"> 

Ahhh, có chúng tôi đi. Trong nháy mắt, mà không biết bất cứ điều gì về sắc thái của hệ thống của bạn, tôi có thể xác định ngay lập tức:

• Trường hợp biến employeeQry đến từ
• gì cache CFC tôi kêu gọi các truy vấn từ
• Đó Tôi gọi một và chỉ một truy vấn và không phải khối lượng bao gồm một loạt truy vấn, không cần truy vấn nào cho trang.

Việc đóng gói logic nghiệp vụ trong một lớp dịch vụ (CFC) làm tăng khả năng đọc mã của bạn, điều này sẽ tạo sự khác biệt khi bạn tham gia chủ đề tiếp theo.

Maintenance

Bạn nhận được một tổ chức của một ứng dụng CF mới mà bạn đang phụ trách, và mở ra trang nhân viên để tìm ra <cfinclude template="_queries.cfm"> mẫu ở trên.

Bên trong đó, nhà phát triển ban đầu để lại nhận xét nói rằng: "Không chạy tất cả các truy vấn, hãy chạy truy vấn cụ thể dựa trên tham số", và sau đó bạn thấy một cái gì đó như sau:

<cfswitch case="#param#"> 
    <cfcase value="employee"> 
    <cfinclude template="_employeeQry.cfm"> 
    </cfcase> 
    <cfcase value="employees"> 
    <cfinclude template="_employeesQry.cfm"> 
    </cfcase> 
    <cfcase value="employeesByDept"> 
    <cfinclude template="_employeesByDept.cfm"> 
    </cfcase> 
</cfswitch> 

... để bạn xem xét điều này và nghĩ rằng, cũng ... tôi cần phải sửa đổi các truy vấn employeesByDept, vì vậy bạn crack mẫu mà mở và tìm thấy:

<!--- employees by department ---> 
<cfif args.order_by is "ASC"> 
    <cfinclude template="_employeeQryByDeptOnASCOrder.cfm"> 
<cfelse> 
    <cfinclude template="_employeeQryByDeptOnDESCOrder.cfm"> 
</cfif> 

... và của thành viên này điểm, bạn muốn bắn mình vào mặt.

Đây là một ví dụ phóng đại, nhưng tất cả đều quá quen thuộc trong thế giới ColdFusion; một sở thích trí tuệ khi kiến ​​trúc các ứng dụng cấp doanh nghiệp. Điều này "bao gồm bên trong bao gồm trong bao gồm" cơn ác mộng là một cái gì đó CF phát triển đối phó với thường xuyên hơn bạn có thể nghĩ.

Giải pháp rất đơn giản!

Một CFC duy nhất đóng gói logic nghiệp vụ trong việc tạo truy vấn cho Nhân viên của bạn.

<cfcomponent> 

    <cffunction name="getEmployees" returntype="query"> 

    <cfquery name="tmp"> 
    select employeeID, name, age 
    from employees 
    </cfquery> 

    <cfreturn tmp /> 
    </cffunction> 

    <cffunction name="getEmployeesByDept" returntype="query"> 
    <cfargument name="deptID"> 
    <cfargument name="order_by" required="false" default="ASC"> 

    <cfquery name="tmp"> 
    select employeeID, name, age 
    from employees e 
    inner join empToDept etd on (e.employeeID = etd.employeeID) 
    where etd.deptID = #arguments.deptID# 
    order by name #iif(arguments.order_by is 'asc',de('asc'),de('desc'))# 
    </cfquery> 

    <cfreturn tmp /> 

    </cffunction> 

</cfcomponent> 

Bây giờ, bạn có một điểm duy nhất của tài liệu tham khảo cho tất cả các thông tin mà bạn muốn tạo ra khi truy vấn cơ sở dữ liệu nhân viên của bạn, và có thể parameterize/điều chỉnh nó tất cả cùng một lúc, mà không cần phải khai thác thông qua núi bao gồm trong phạm vi bao gồm bên trong bao gồm ... mà là cồng kềnh, và khó khăn để giữ thẳng (ngay cả với kiểm soát nguồn đầy đủ).

Nó thanh lịch cho phép bạn viết một dòng duy nhất:

<cfset empQry = request.model.queries.getEmployees() /> 

hoặc

<cfset empQry = request.model.queries.getEmployeesByDept(14,'DESC') /> 

và làm cho công việc của bạn duy trì mã đó dễ dàng hơn nhiều.

Việc tuân thủ Paradigms Object-Oriented đã được chứng minh

Sếp của bạn thông báo rằng một rockstar Java đã gia nhập đội. Bạn đang rất háo hức và vui mừng ngồi xuống với anh ta vì bạn chủ yếu bị mắc kẹt trong CF trong vài năm qua, và muốn có cơ hội để cho anh ta xem một số thứ của bạn, và có thể học hỏi từ anh ấy.

"Vậy, ứng dụng có thể truy cập dữ liệu như thế nào?" anh ta hỏi bạn.

"Ồ, chúng tôi có một loạt truy vấn mà chúng tôi gọi trên các trang khác nhau và dựa trên các thông số, chúng tôi sẽ kéo các loại thông tin khác nhau."

"Tốt", anh ấy nói, "Vì vậy ... bạn có một lớp dịch vụ cho mô hình đối tượng dữ liệu, điều đó thật tuyệt."

Không thực sự là, bạn nghĩ vậy.Nó chỉ là bao gồm bên trong bao gồm ... nhưng anh ấy tiếp tục,

"Thật tuyệt vời, bởi vì một trong những điều mới chúng tôi sẽ thêm là đối tượng nhà thầu, về cơ bản là một tập con của nhân viên, anh ta sẽ có một vài chức năng khác nhau, nhưng tổng thể sẽ hoạt động rất giống với Nhân viên. Chúng tôi sẽ tiếp tục và phân lớp nhân viên, và ghi đè một số truy vấn đó ... "

... và bây giờ bạn bị mất . Bởi vì không có lớp con bao gồm. Không có kế thừa trong một bao gồm. Một bao gồm không có kiến ​​thức về một tên miền hoặc một đối tượng kinh doanh, hoặc làm thế nào nó được cho là tương tác với các đối tượng khác.

Một cfinclude là một tiện ích để sử dụng lại các yếu tố chung, như đầu trang hoặc chân trang. Họ không phải là một cơ chế để phản ánh sự phức tạp của một đối tượng kinh doanh.

Khi bạn thiết kế/xây dựng/triển khai CFC làm đối tượng phản ánh các thực thể trong ứng dụng của bạn, bạn đang nói một ngôn ngữ chung: OO. Nó có nghĩa là nó không cung cấp cho bạn khả năng thiết kế một hệ thống dựa trên một cấu trúc đã được chứng minh, nó mở rộng ngôn ngữ của "OO-ness" cho các lập trình viên trong các công nghệ khác. Lập trình viên Java, lập trình viên C++/C#, v.v ... bất cứ ai có kiến ​​thức hợp lý về phát triển hướng đối tượng sẽ tự động nói ngôn ngữ của bạn và có thể làm việc với bạn và hệ thống của bạn.

Chú ý đến lưu ý cuối cùng này: Không phải mọi ứng dụng đều cần hướng đối tượng. Nếu sếp của bạn muốn bạn roi một đoạn XML nhanh chóng của bảng nhân viên và tát nó trên trang web - vâng, bạn có thể bỏ qua toàn bộ mô hình oo cho điều đó. Nhưng nếu bạn đang xây dựng một ứng dụng từ đầu, và nó sẽ giới thiệu nhân viên, người dùng, phòng ban, truy vấn, vai trò, quy tắc, vé ... ngắn gọn: các thực thể trong một miền, sẽ là thời gian để bỏ qua các cfincludes là công cụ chính của bạn để sử dụng lại mã.

Ồ, và PS: Ghi chú nhỏ mà tôi để lại ở đầu về việc thu gom rác thải - không phải là trò đùa. Tôi đã thấy các ứng dụng CF được xây dựng không chính xác, do đó bản thân Application.cfc gọi là cfincludes và sau khi gắn kết CF lên một JVM that can monitor realtime creation/destruction of objects in the GC, tôi đã nhìn thấy bộ nhớ giống như màn hình EKG.

Không tốt.

Answer 2

Phản ứng của Shawn chắc chắn bao gồm các điểm chính. Để tóm tắt tất cả những điều đó vào những điểm mấu chốt mà sếp của bạn sẽ hiểu .. cách tiếp cận CFC sẽ giúp anh tiết kiệm rất nhiều tiền trong việc bảo trì, và sẽ giữ cho các nhà phát triển của mình hạnh phúc hơn vì công việc của họ sẽ dễ dàng hơn nhiều, và tỷ lệ lưu giữ của các nhà phát triển có kỹ năng/năng động sẽ cao hơn rất nhiều so với nếu anh ta ở lại với mã spaghetti như một tiêu chuẩn.

Answer 3

Tôi đồng ý hoàn toàn với phản hồi của Shawn ... và nếu bạn muốn đưa mã của mình lên cấp cao hơn, hãy sử dụng khung! Sau đó, nó thực sự sẽ giúp bạn tiết kiệm và các nhà phát triển khác rất nhiều thời gian, vì mọi người sẽ tuân thủ các tiêu chuẩn riêng của mình.

Sở thích cá nhân của tôi là Coldbox, nhưng bất kỳ khung MVC/OO phổ biến nào sẽ làm - Coldbox, Mach-II, Model-Glue, FW/1. Tôi đã nghe những điều tốt đẹp về CFWheels nhưng không sử dụng nó.