Có thể ghép một cách lỏng lẻo một ứng dụng vào khuôn khổ của nó không?

Giả sử tôi đang phát triển một ứng dụng web. Lựa chọn đầu tiên của tôi là sử dụng PHP với Fat-Free Framework (F3) và mẫu MVC. Năm tới, tôi có thể quyết định tôi muốn chuyển sang Zend Framework, hoặc thậm chí là ASP.NET MVC. Liệu nó có ý nghĩa để thử và thiết kế ứng dụng của tôi theo cách mà nó được kết nối lỏng lẻo với khung của nó, hoặc là khung quá tách rời để thực hiện điều này?

Lý do duy nhất tôi hỏi là vì nó xuất hiện trong cuộc trò chuyện với một người ngang hàng gần đây, người đã chỉ trích chiếc bánh của tôi trên bầu trời ý tưởng về việc ghép lỏng ứng dụng của tôi với F3.

Kết nối lỏng lẻo ứng dụng của bạn với khung của nó về cơ bản có nghĩa là bạn sẽ viết một khung proxy. Viết khung proxy đó là rất nhiều công việc và nếu bạn từng chuyển sang một khung mới, bạn sẽ phải làm rất nhiều việc để làm cho khung proxy hỗ trợ khung mới. Tất nhiên, các khung khác nhau sử dụng các thành ngữ và mẫu khác nhau, điều này sẽ làm cho khung proxy trở nên rất phức tạp (nếu bạn cố gắng làm cho nó phù hợp với mọi thứ) hoặc rất hạn chế (nếu bạn đi theo mẫu số chung thấp nhất). Dù bằng cách nào, bạn sẽ phải vật lộn với khung proxy đó.

Là có khả năng thay đổi khuôn khổ trên một giá trị tất cả những rắc rối này? Giống như tôi đã nói, bạn sẽ không thể thay đổi bất cứ điều gì vì bạn sẽ phải điều chỉnh khung proxy, điều này có thể sẽ hiệu quả hơn là điều chỉnh trực tiếp mã ứng dụng.

Không thể làm.

Bạn có thể thiết kế theo cách di động trên các khung. MVC là MVC và các nguyên tắc gần như giống nhau với bất kỳ ngôn ngữ hoặc nền tảng nào được sử dụng.

Mã thực tế, tuy nhiên, sẽ rất phụ thuộc vào khuôn khổ hoặc ngôn ngữ. Cách duy nhất để trừu tượng bản thân khỏi đó là viết mã dựa trên khung trung gian. Sau đó, bạn có thể có thay đổi triển khai trung gian (từ F3 sang .NET?) Mà không thay đổi ứng dụng. Đó là rất nhiều công việc, giả định trừu tượng không rò rỉ, và chỉ di chuyển vấn đề mà không giải quyết nó: bây giờ bạn đang bị ràng buộc với khung trung gian của bạn.

Trên một lưu ý tích cực hơn: xem xét thể hiện một số thử nghiệm của bạn (kiểu BDD) trong một nền tảng độc lập với việc triển khai của bạn. Những người có thể sống sót viết lại lớn.

Tôi đã từng thấy Robert C. Martin nói chuyện trong đó anh ấy nói điều gì đó dọc theo dòng chữ "quyết định đầu tiên bạn đưa ra là quyết định khó nhất để thay đổi sau này".

Vì vậy, lời khuyên của tôi là cố gắng trì hoãn quyết định này nếu bạn chưa chắc chắn chính xác những gì bạn muốn sử dụng. Xác định các phần mà bạn có thể xác định ngay bây giờ và sẽ dễ dàng độc lập với bất kỳ khuôn khổ nào bạn kết thúc sử dụng.

Khóa khung có thể là một vấn đề nghiêm trọng, nhưng nó giúp xem vấn đề là một trong những tính di động. Tính di động không phải là một thuộc tính tuyệt đối, nhưng liên quan đến điểm xuất phát của bạn và nơi bạn có thể muốn đi. Bằng cách tương tự, sau đó, phần mềm chỉ có thể mang theo khi bạn đã chuyển nó sang các môi trường khác.

Hầu hết sự phát triển của một ứng dụng bên trong một khung có xu hướng là mã keo, thứ gắn kết các thành phần của khung với nhau. Các tệp cấu hình có thể trừu tượng một lượng keo nhất định trong một số hệ thống nhưng rất nhiều chi tiết tốt phải được thực hiện trong mã.

Mặt khác, các quy tắc và quy trình kinh doanh có thể được trừu tượng hóa từ ứng dụng. Phần khó của sự trừu tượng là khi các quy tắc được thực hiện trực tiếp bởi khung; bảo mật, khả năng truy cập và trình tự quy trình có xu hướng được thi hành theo khuôn khổ của bạn và có thể khó thấy nhất.

Nếu bạn có thể tách phần keo của ứng dụng của bạn khỏi quy tắc kinh doanh và quy trình kinh doanh và phần dữ liệu kinh doanh, thì bạn sẽ có thể thực hiện một số phần của giải pháp của mình.