framework ve a kütüphanesi arasındaki fark nedir?
Bir kütüphaneyi her zaman belirli bir problemi veya belirli bir uygulama geliştirme alanını (yani veritabanı erişimi) çözmeye odaklanan bir dizi nesne ve işlev olarak düşündüm; ve diğer yandan, belirli bir metodolojiye (yani MVC) odaklanan ve uygulama geliştirmenin tüm alanlarını kapsayan bir kütüphaneler koleksiyonu olarak bir çerçeve.
Aslında bu terimler, kullanıldığı bağlama bağlı olarak birçok farklı anlam ifade edebilir.
Örneğin, Mac OS X'te çerçeveler sadece bir paket halinde paketlenmiş kütüphanelerdir. Paketin içinde gerçek bir dinamik kütüphane bulacaksınız (libWhatever.dylib). Çıplak bir kütüphane ve Mac'teki çerçeve arasındaki fark, bir çerçevenin kütüphanenin birden çok farklı sürümünü içerebilmesidir. Ekstra kaynaklar içerebilir (resimler, yerel dizeler, XML veri dosyaları, UI nesneleri vb.) Ve çerçeve halka açıklanmadıkça, genellikle kütüphaneyi kullanmanız için gereken gerekli .h dosyalarını içerir.
Böylece, uygulamanızdaki kütüphaneyi kullanmanız için gereken tek bir paketteki her şeye sahipsiniz (.h dosyaları olmayan bir C/C++/Objective-C kütüphanesi, bir kütüphane dokümantasyonuna göre yazmazsanız, oldukça işe yaramaz). dolaşmak için bir sürü dosya (bir Mac paketi sadece Unix seviyesindeki bir dizindir, fakat kullanıcı arayüzü tek bir dosya gibi davranır, tıpkı Java'da JAR dosyalarınız olduğu ve tıklattığınızda genellikle görmezsiniz) içeriğini göstermeyi açıkça seçmediğiniz sürece, içinde ne olduğunu).
Vikipedi çerçeveye bir "terim" diyor. Yazılım çerçevesini şu şekilde tanımlar:
Yazılım çerçevesi, bir yazılım sistemi (veya alt sistemi) için yeniden kullanılabilir bir tasarımdır. Bir yazılım çerçevesi, bir yazılım projesinin farklı bileşenlerinin geliştirilmesi ve yapıştırılması için destek programları, kod kütüphaneleri, bir komut dosyası dili veya başka bir yazılım içerebilir. Çerçevenin çeşitli bölümleri bir API aracılığıyla gösterilebilir.
Yani bir kütüphanenin sadece "bir kütüphane" olduğunu söyleyebilirim. Bir nesneler/işlevler/yöntemler topluluğudur (dilinize bağlı olarak) ve uygulamanız buna karşı “bağlantı kurar” ve böylece nesneler/işlevler/yöntemler kullanabilir. Temelde, genellikle birden fazla uygulama arasında paylaşılabilen yeniden kullanılabilir kod içeren bir dosyadır (aynı kodu tekrar tekrar yazmak zorunda değilsiniz).
Bir çerçeve, uygulama geliştirmede kullandığınız her şey olabilir. Bir kütüphane, birçok kütüphane koleksiyonu, bir komut dosyası koleksiyonu veya uygulamanızı oluşturmak için ihtiyaç duyduğunuz herhangi bir yazılım olabilir. Çerçeve sadece çok belirsiz bir terimdir.
İşte bazı konular hakkında " Library vs. Framework " konulu bir makale. Ben şahsen bu makalenin oldukça tartışmalı olduğunu düşünüyorum. Orada ne söylediği yanlış değil, ancak, çerçevenin çoklu tanımlarından birini seçti ve bunu klasik kütüphane tanımıyla karşılaştırdı. Örneğin. Alt sınıflandırma için bir çerçeveye ihtiyacınız olduğunu söylüyor. Gerçekten mi? Bir kütüphanede tanımlanmış bir nesneye sahip olabilirim, ona karşı bağlayabilirim ve kodumda onu alt sınıflandırabilirim. Bunun için nasıl bir "çerçeveye" ihtiyacım olduğunu anlamıyorum. Bir şekilde, çerçeve teriminin bugünlerde nasıl kullanıldığını açıklamak yerine. Daha önce söylediğim gibi, sadece sinirli bir Word. Bazı şirketler (normal bir kütüphanenin herhangi bir anlamında) sadece normal bir kütüphane yayınlarlar ve “fantezi” olarak adlandırırlar çünkü daha hoş geliyor.
A library belirli, iyi tanımlanmış işlemleri gerçekleştirir.
A framework, uygulamanın iskeleti doldurarak işlemin "etini" tanımladığı bir iskelettir. İskeletin parçaları birleştirmek için hala bir kodu vardır, ancak en önemli iş uygulama tarafından yapılır.
Kütüphanelere örnekler: Ağ protokolleri, sıkıştırma, görüntü işleme, dize programları, düzenli ifade değerlendirmesi, matematik. İşlemler kendi kendine yetiyor.
Çerçeve örnekleri: Web uygulama sistemi, Eklenti yöneticisi, GUI sistemi. Çerçeve kavramı tanımlar ancak uygulama son kullanıcıların ilgilendiği temel işlevleri tanımlar.
Bence asıl fark, çerçevelerin “ Hollywood ilkesini ”, yani “bizi arama, sizi arayacağız” izlemesidir.
Martin Fowler 'a göre:
A kütüphanesi temelde arayabileceğiniz bir işlevler dizisidir, bugünlerde genellikle sınıflara ayrılmıştır. Her çağrı bir miktar işlem yapar ve kontrolü müşteriye geri verir.
A çerçevesi , bazı soyut tasarımları içerir, daha fazla davranış yerleşiktir. Kullanmak için davranışınızı çerçevedeki çeşitli yerlere eklemeniz gerekir. alt sınıflandırma veya kendi sınıflarınızı takarak. Çerçevenin kodu daha sonra kodunuzu bu noktalardan çağırır.
Bu sadece bir toplama / yordamları (işlevsel programlama) veya sınıf tanımları (nesne yönelimli programlama). Bunun nedeni basitçe code reuse , yani daha önce diğer geliştiriciler tarafından yazılmış olan kodları almak. Sınıflar veya rutinler normal olarak etki alanına özgü bir alanda belirli işlemler tanımlanır. Örneğin, bir algoritmanın nasıl çalıştığını tekrarlamadan geliştiricinin sadece fonksiyonu çağırmasını sağlayan bazı matematik kütüphaneleri vardır.
Çerçevede, tüm kontrol akışı zaten var ve , önceden tanımlanmış bir sürü beyaz nokta var biz kodumuzu doldurun . Bir çerçeve normalde daha karmaşıktır. , bir iskeleti tanımlar; burada uygulama, iskeleti doldurmak için kendi özelliklerini tanımlar. Bu şekilde, kodunuz uygun olduğunda çerçeveyle çağrılacaktır. Bunun yararı, geliştiricilerin bir tasarımın iyi olup olmadığı konusunda endişelenmelerine gerek kalmaması değil, yalnızca alana özgü işlevleri uygulama konusunda endişelenmelerine gerek olmamasıdır.
Bir kütüphane ve bir çerçeve arasındaki temel fark: “Denetimin Tersine Çevirilmesi” . Bir kütüphaneden bir yöntem çağırdığınızda, kontrol sizdedir. Ancak bir çerçeveyle kontrol ters çevrilir: çerçeve sizi çağırır . Kaynak.
Her ikisi de programcıların kullanması için kullanılan API'yi tanımladı. Bunları bir araya getirmek için, bir kütüphaneyi bir uygulamanın belirli bir işlevi, uygulamanın iskeleti olarak bir çerçeve olarak düşünebiliriz ve bir API bunları bir araya getirmek için bağlayıcıdır. Tipik bir geliştirme süreci normalde bir çerçeve ile başlar ve kütüphanelerde API ile tanımlanmış işlevleri doldurur.
Kütüphaneyi ara.
Çerçeve seni çağırıyor.
図 書館 助 け
足 場 が 痛 い
多 く の 涙
Her zaman tarif ettiğim gibi:
Bir Kütüphane bir araçtır.
Bir çerçeve yaşam tarzıdır.
Küçük parçaların size yardımcı olduğu her şeyi kullanabileceğiniz bir kütüphane. Tüm projenizi taahhüt etmeniz gereken bir Çerçeve.
Cohens'un cevabını seviyorum, ama daha teknik bir tanım: Kodunuz bir kütüphane çağırıyor. Bir çerçeve kodunuzu çağırır. Örneğin, bir GUI çerçevesi, kodunuzu olay işleyicileri aracılığıyla çağırır. Bir web çerçevesi kodunuzu bazı istek-cevap modelleriyle çağırır.
Buna aynı zamanda kontrolün tersine çevrilmesi de denir - çerçeve bir anda kitaplıklardaki diğer yollardan ziyade kodunuzu ne zaman ve nasıl yürüteceğinize karar verir. Bu, bir çerçevenin kodunuzu nasıl yapılandırmanız gerektiği üzerinde çok daha büyük bir etkiye sahip olduğu anlamına gelir.
Web geliştirici bakış açısından:
Kütüphane başka bir kütüphane tarafından kolayca değiştirilebilir. Ancak çerçeve olamaz.
Jquery tarih seçici kitaplığından hoşlanmıyorsanız, önyükleme tarihi seçici ya da kazma gibi başka bir tarih seçiciyle değiştirebilirsiniz.
Ürününüzü kurduğunuz AngularJS'ten hoşlanmıyorsanız, başka hiçbir çerçeveyle değiştiremezsiniz. Tüm kod tabanınızı yeniden yazmak zorundasınız.
Çoğunlukla kütüphane, Frameworks ile karşılaştırıldığında çok daha az öğrenme eğrisi alır. Örneğin: underscore.js bir kütüphanedir, Ember.js bir çerçevedir.
Bu tanımı nerede gördüğümü unuttum, ama sanırım bu oldukça hoş.
Bir kitaplık, kodunuzdan çağıracağınız bir modüldür ve çerçeve, kodunuzu çağıran bir modüldür.
Farklı kütüphanelerden bir çerçeve yapılabilir. Bir örnek alalım.
Bir balık körili yemek yapmak istediğinizi varsayalım. O zaman oil, spices ve diğer tilities gibi bileşenlere ihtiyacınız var. Ayrıca yemeğinizi hazırlayabilmeniz için üssü olan fish uygulamasına ihtiyacınız var (Bu, uygulamanızın verileridir). tüm içerikler birlikte framework olarak adlandırılır. Şimdi onları nihai ürününüz olan balık körinizi yapmak için tek tek veya kombinasyon halinde kullanacaksınız. Bunu, nderscore.js, bootstrap.css, bootstrap.js, fontawesome, AngularJS ile yapılmış bir web çerçevesi ile karşılaştırın. vb. Bir örnek için, Twitter Bootstrap v.35.
Şimdi, sadece bir bileşen düşünürseniz, oil deyin. İstediğiniz herhangi bir yağı kullanamazsınız çünkü o zaman balığınızı mahveder (veriler). Sadece Zeytin Yağı kullanabilirsiniz. Bunu nderscore.js ile karşılaştırın. Şimdi kullanmak istediğiniz hangi marka yağ size kalmış. Bazı yemekler Amerikan Zeytinyağı (underscore.js) veya Hint Zeytinyağı (lodash.js) ile yapıldı. Bu sadece uygulamanızın tadını değiştirecektir. Neredeyse aynı amaca hizmet ettikleri için kullanımları geliştiricinin tercihine bağlıdır ve kolayca değiştirilebilirler.
Framework: Uygulamanıza benzersiz özellikler ve davranışlar sağlayan bir kütüphaneler koleksiyonu. (Tüm malzemeler)
Library: Verilerinize benzersiz özellikler ve davranışlar sağlayan iyi tanımlanmış bir talimatlar seti. (Balık Yağı)
Eklenti: Eklentinizin şimdi beklendiği gibi çalışabileceği bir kütüphane (ui-router -> AngularJS) veya bir çok kütüphane için birleşik derleme (date-picker -> bootstrap.css + jQuery).
Not; AngularJS bir MVC çerçevesi fakat bir JavaScript kütüphanesidir. Çünkü Kitaplığın yerel teknolojinin varsayılan davranışını genişlettiğine inanıyorum (bu durumda JavaScript).
Bunu böyle düşünüyorum (ve başkaları tarafından rasyonalize etmiş halde gördüm):
Bir kitaplık, kodunuzun içinde bulunan bir şeydir. Ve bir çerçeve, uygulamanız için bir konteynerdir.
burada bir Joel Spolsky tarafından yapılan acı makale ile bağlantılıdır, ancak araç kutuları, kütüphaneler, çerçeveler ve benzerleri arasında iyi bir ayrım vardır
Bir kütüphane, dar kapsamlı bir amaç için işlevsellik uygularken, bir çerçeve daha geniş bir özellik yelpazesine destek sağlayan bir kütüphane koleksiyonu olma eğilimindedir. Örneğin, System.Drawing.dll kütüphanesi çizim işlevini kullanır, fakat genel .NET çerçevesinin sadece bir parçasıdır.
Kütüphane - İstemci olarak kullanılabilecek herhangi bir sınıf veya bileşen kümesi, belirli bir görevi yerine getirmek için uygun görür.
Çerçeve - sizden daha büyük birşeye "eklenti" yapmanız için bazı yönergeleri zorunlu kılar. Uygulamanıza/gereksinimlerinize özgü parçaları yalnızca yayınlanmış bir şekilde sağlarsınız, böylece 'çerçeve işi hayatınızı kolaylaştırabilir'
Kütüphaneler kullanım kolaylığı ve verimlilik içindir. Örneğin Zend kütüphanesinin iyi tanımlanmış sınıfları ve işlevleri ile farklı görevleri yerine getirmemize yardımcı olduğunu söyleyebilirsiniz. Bir çerçeve, genellikle MVC (Model gibi) bir çözümü uygulamaya koymaya zorlayan bir şeydir. -View kontrol cihazı) (referans) . MVC.Model'deki gibi görevlerin dağıtımı için iyi tanımlanmış bir sistemdir. Model veritabanı tarafı, Görünümler UI Arayüzü içindir ve kontrolörler İş mantığı içindir.
Bence farkı çok iyi düştünüz: çerçeve, çalışmamızı yaptığımız bir çerçeve sunuyor ... Bir şekilde, basit bir kütüphaneden daha "sınırlayıcı".
Çerçevenin bir dizi kütüphaneye tutarlılık eklemesi de gerekiyordu.
Kütüphanenin bir hedefe ulaşmak için bir takım yardımcı programlar olduğunu düşünüyorum (örneğin, soketler, şifreleme vb.). Çerçeve kütüphane + RUNTIME EINVIRONNEMENT. Örneğin, ASP.NET bir çerçevedir: HTTP isteklerini kabul eder, sayfa nesnesi oluşturur, lyfe cicle olaylarını çağırır, vb. Çerçeve tüm bunları yapar, belirli bir yaşam süresinde çalıştırılacak olan bir kod yazmışsınızdır. Mevcut istek!
Her neyse, çok enteresan bir soru!
Bu cevabın kaynağını hatırlamıyorum (sanırım internette bir .ppt içinde buldum), ancak cevap oldukça basit.
Bir Kütüphane ve bir Çerçeve, uygulamalarınızda kullanabileceğiniz ve belirli bir "sorunu" çözmenize yardımcı olacak bir dizi sınıf, modül ve/veya koddur (programlama diline bağlı olarak).
Bu sorun, bir uygulamadaki bilgileri günlüğe kaydetmek veya hata ayıklamak, grafik çizmek, belirli bir dosya formatı (html, pdf, xls) oluşturmak, bir veri tabanına bağlanmak, bir uygulamanın bir parçası veya tam bir uygulamanın veya uygulamaya uygulanan bir kod olabilir. Tasarım Deseni .
Tüm bu problemleri çözmek için bir Çerçeveye veya Kütüphaneye sahip olabilirsiniz ve daha pek çoğu, normal olarak çerçeveler daha karmaşık veya daha büyük problemleri çözmenize yardımcı olur, fakat temel farkın bir ana tanımı değil ikisi için.
Bir Kütüphane ve Bir Çerçeve arasındaki ana fark, bir Çerçeveyi kullanmak için, kendi kodlarına olan bağımlılıktır, bir Çerçeveyi kullanmak için, FW'deki hemen hemen tüm sınıfları, modülleri veya kodu kullanmanız gerekir. Bir Kütüphane kullanmak için kendi uygulamanızdaki kütüphanede bir veya birkaç sınıf, modül veya kod kullanabilirsiniz
Bu, eğer bir Çerçevenin, örneğin, kullanmanız gereken bir uygulamada çerçeveyi kullanmak için 50 sınıfa sahip olması durumunda, kodunuzda 10-15 veya daha fazla sınıf olduğunu söyleyin; sınıflar (bu sınıfların nesneleri), çerçevedeki diğer sınıflardaki yöntemler için girdi/parametrelerdir. .NET çerçevesi, Spring veya herhangi bir MVC çerçevesine bakın.
Ancak, örneğin bir günlük kütüphanesi, kodunuzda sadece bir Günlük sınıfı kullanabilirsiniz ve “günlük kaydı problemini” çözmenize yardımcı olur; bu, günlük kütüphanesinin kendi sınıfında olduğu gibi kodunda daha fazla sınıf bulunmadığı anlamına gelmez. dosyaları işlemek, ekran çıktılarını ve hatta veri tabanlarını işlemek için, ancak kodunuzdaki bu sınıflara asla dokunmaz/kullanmazsınız ve bu neden bir kütüphane değil de bir çerçeve değildir.
Ayrıca, Çerçeveler ve Kütüphanelerden daha fazla kategori var, ama bu konu dışı.
Yorumunuz benim için oldukça iyi geliyor ... A library başka bir kodda tekrar kullanmak için derlenmiş ve kendi kendine yeten herhangi bir şey olabilir, kelimenin tam anlamıyla içeriğinde hiçbir kısıtlama yoktur.
Öte yandan, bir çerçeve 'nin, örneğin MVC gibi, uygulamanızın belirli bir arenasında kullanım için çeşitli olanaklara sahip olması beklenir.