As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have read in "Design Patterns" book for the gang of four that the framework influences the overall architecture of the Application. Now I know for example when using .NET that you need to inherit from System.Windows.Form to make a form (Although I think I am having a big misconception here). But can anyone describe in code using any framework how does the framework affect the application architecture?
There are some interesting notes about the topic in Wikipedia:
Software frameworks consist of frozen spots and hot spots. Frozen
spots define the overall architecture of a software system (...).
These remain unchanged (frozen) in any instantiation of the
application framework. Hot spots represent those parts where the
programmers using the framework add their own code (...).
According to that, your application can be defined by the Frameworks you're using. For example, in the Java World using Struts frameworks implies that you're using an MVC architecture, or using Spring Framework forces you to apply the Dependency Injection Pattern. If Software Architecture is defined by software patterns, then some frameworks are pre-built patterns for you to utilize.
On the other side, no Software Application is made only by Patterns/Frameworks, an there's were the Hot Spots are usefull: they're ways that Software Frameworks offer to extends/use the frameworks capabilities and build an application according to your requirements and domain.
For example, let's say you're building a Web Application using Spring MVC Framework. After you configure the Framework in your project, every request for your application will be delegated to a class called DispatcherServlet. This class is built-in in the Framework and you shouldn't modify it, so it's a perfect example of a Frozen Spot. The DispatcherServlet will look-up your project configuration and delegate request processing to a Controller. The Controller is typically a class made by the programmer and has the responsability to process the request. So your hand-made controller it's a Hot Spot for you to extend the Framework.
And the DispatcherServlet is an Implementation of the Front-Controlller Patttern, and the Controller usage is typicall of an MVC application; so your application is highly defined by the framework you're using.
I must say that a clean Architecture(also Design Patterns) does not depend on which frameworks, toolkits or library are being used. An architecture describes the high level structure of a software system(layers and tiers), not in details how it is implemented. it's a set of principles that help us to achieve some specific goals such as security, usability, extensibility, reliability, maintainability, availability... Let's see a simple example:
Model–view–controller (MVC) is a software architecture(or design pattern) that separates the modeling of the domain, the presentation, and the actions based on user input into three separate classes. The central idea behind MVC is code reusability and separation of concerns. You can apply MVC using many programming languages or frameworks like ASP.Net MVC, Java Strut, PHP DRY, CAKEPHP....
There are different approaches in ways of passing, storing or evaluating data in different frameworks. IF you're working with a Windows Form application, you can reach your view elements from anywhere of the project, since they are all in the computer's local memory and nowhere else.
However, if you're working with an ASP.NET application, there are different sides consuming the project, client and server and things get more complex. The design you're making has almost nothing common with Forms.
If you're working with an ASP.NET MVC application, there are three tiers: ModelViewController, and operations are divided into these and from now on, you need to do your design in a way that fits with these tiers. You have database table-object relations provided by MVC which could change the design totally.
Also programming language lying beneath the program changes the design, as it can be functional, object-oriented etc.
In short, this is not a constructive question. You'll figure out this questions answer after working with different programming languages and technologies.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I have an ASP.NET MVC 4 project and I'm stuck on an architectural decision on which JavaScript framework or library to use Angular.js or Knock.js. I am currently leaning towards using Angular.js over Knockout.js, but don't want to find out midway during project development I made a mistake.
Here is some background:
We need two-way model data binding
We need the ability to test views. I want to be able to do end to end unit testing. Also, we are using continuous integration.
"Save Changes" functionality. i.e. if a user makes changes on a page we need the ability to detect any changes and prompt the user to save their changes before they navigate away from the page
"Notifications" functionality. i.e. user will be logged on approximately 8 hours and will need to be notified and updated of changes made by other users (errors, data status changes and the like)
We need to "future proof" our application. Currently the business unit hasn't decided if we will need to support mobile devices, but I know it's just a matter of time.
Our team consists of developers with varying experience levels from very junior to senior developers.
Currently our models are complicated and may get even more so
We need to also consider RAD, code reuse, and maintainability
I have read the excellent answer here and watched Scott Allen's interview about Angular here
Since we are unable to change from our current ASP.NET MVC 4 architecture to use something on the server side like Web API I have some concerns in trying to implement Angular.js with MVC 4. Will this cause us to have two models one on the server and one on the client?
I am not looking for a "which is better" discussion about Angular and Knockout because I think they both have their pros and cons. I am looking for actual code on implementing a JavaScript framework or library in an ASP.NET MVC 4 application. I need a solution that I can live with 2+ years from now :)
Any ideas or suggestions? Maybe the answer is not Knock or Angular, but some other JavaScript framework?
my 2 cents worth.
preamble - i have worked with both angular and knockout.
I'm on my 3rd non trivial front end built with a MVVM/MVC lib.
I started with knockout because its MVVM is very similar to the wpf/silverlight mechanics. And it works well. The tutorials and documentation are top notch. All your coders will be able to work with knockout.js within days or if they have used mvvm under .net, then within hours.
However, these days I am using angular and will probably stick with it for the following reasons.
angular is a complete framework - knockout is really about just the 2
way binding. you still need other libraries like backbone.js/jquery
to do the rest of your work.
angular has dependency injection. which is perfect for adding
mocking for testing as well as giving structure to your code.
angular treats normal JS variables as observables within its $scope
object. that means you dont have to declare them in a special way
I'm not an angular fanboy, i still think they could move more over to the MVVM architecture instead of the "funky" MVVM/MVC hybrid architecture they currently have.
The biggest problem with angular is the documentation. Compared to knockout, it is woeful. It will add additional time and cost to getting your coders up to speed. Once they are there however, it is currently the best choice IMHO.
Glad to see this questions was of interest to the community ;) Just for completeness here's what I ended up doing:
I did go with AngularJS and ASP.NET MVC 4 and was glad that I did. Although, Angular has a steep learning curve but its worth it because of the power of directives.
We need two-way model data binding - On occassion I needed to set some initial values coming from the MVC controller. I used the ng-init attribute to accomplish this.
We need the ability to test views - I followed the AngularJS docs for testing
"Save Changes" functionality - I implemented this using a directive in Angular
"Notifications" functionality - I implemented this using toastr.js and and directives (schweet)
We need to "future proof" our application - I don't know Google's plans for AngularJS, but after working with AngularJS I can't see it going anywhere anytime soon and expected it to become more widely adopted :)
I don't have a lot of input on AngularJs, but want to provide some thoughts on Knockout.
Knockout is primarily a data-binding library to connect views to view model, but doesn't really provide a lot of capabilities beyond that. I wouldn't recommend using knockout alone as the main library to build a complex client-based web site.
You didn't mention whether you're implementing spa-like functionality (i.e. hash-tag navigation) or whether you're primarily using MVC server-side views (e.g. Razor). If you're just looking for quick data-binding on a per-page level, I would even reconsider that. To me, both of these (angular or knockout) are designed to enhance the client-side development experience - not so much a server-side approach such as MVC.
If you're considering an SPA approach, even in part, you'll likely want some framework that provides some level of control over the view activation life cycle.
As far as data-binding power and reliability, I believe in Knockout. I have been using it extensively, and have grown quite fond of it. If you like the feel of knockout, you may want to look into Durandal. Durandal is a decent framework is able to meet the needs of many "spa" web projects. It's a client-side framework built on top of several proven libraries, including Knockout. It's a little (lot) more light-weight than Angular, and possibly easier to user.
We are building a fairly large ASP.Net MVC web site using Durandal with Knockout in conjunction with an additional facade to tighten things up from a development standpoint, and the integration with ASP.Net MVC is straight-forward. I don't recommend trying to use the server-side knockout stuff that's out there; I just find that to limit the real power of the MVVM pattern.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Could you tell me the open source alternatives to WCF??
I'm a newbie and just started using WCF. I wanted to know about the alternatives that are open source too.
Also, what makes them better options/not so good compared to WCF.
Thanks,
Thothathri
There are open source projects for REST services - for example Open Rasta Perhaps you will also find some open source projects for basic SOAP services but I doubt that there is an open source project implementing all WS-* related stuff implemented in WCF. WS-* protocols are mostly implemented only in API from big companies - MS, IBM, Oracle, SAP, etc. Reasons are:
Complexity - implementing WS-* protocols means diving deep into tons of specifications. You must also implement them very carefully to be really interoperable and to do not reduce performance too much.
Support - WS-* protocols are usually used in B2B solutions where enterprises demands some guarantees and support.
Costs - developing such API takes really long time.
Even WCF implements only subset of WS-* protocols. But WCF is highly extensible so anybody can try to implement some of these missing protocols himself.
WCF doesn't states only for REST and SOAP services. It is also replacement of .NET Remoting and Enterprise services from older .NET versions. You will not find a .NET API which will also offer all this functionality.
I also highly recommend checking out ServiceStack, it's a config-free web service framework I started that lets you easily and rapidly develop web services with very little friction.
It provides an expressive friction-less environment as you're able to develop web services by using you're own POCO C# DTO's which also encourages best-practices web service development since you're easily able to create more batch-full, coarse-grained APIs.
It's aims to be more productive by closely fusing C# with HTTP where all C# objects returned get automatically serialized to the requested format with (XML, JSON, JSV, CSV, SOAP 1.1/1.2, HTML) supported out-of-the-box. C# Exceptions also get automatically serialized for you making the tedious things effortless.
One of the major benefits is not needing to be concerned with external formats and endpoints (which are taken care by the framework) and you're left with developing your logic in a clean-room, auto-wired and highly testable, DDD-like IService class.
You could use RestCake if you're trying to create RESTful services.
Mono project has an ongoing effort for WCF hosted in Github. As you know, System.ServiceModel is the main engine for WCF. You can find Mono implementations of these namespaces under /mono/mcs/class/System.ServiceModel.* . You can find project related updates and relevant contribution information here
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Why is the Mono project implementing WCF interfaces and classes "as is"?
I do not understand what is the point to repeat Microsoft's design. My experience says that WCF is a huge framework with an implementation based on SOAP services. There are tremendous problems with their approach. It simply does not fit well for simple HTTP request processing cycle. Why not try to invent a better framework instead?
Update:
OK, I get it. :) I like the .NET platform, C# and I like that this platform is available on another OS, but ...
Don't you guys see that many things in the original (Microsoft) frameworks can be done better?
Look at System.ServiceModel.Channels.Message. This is one of big things of customization landscape.
Why do I see XML everywhere? How can I easily do anything with classes like this? It is feasible, but I cannot say this is good design for a general purpose communication framework. I thought that the purpose of the Mono project is not just bringing the .NET ecosystem to unix* but make it better.
I think the whole point is to make WCF platform available in other operating systems than Microsoft Windows. So, if you have an application developed with MS VisualStudio (Microsoft's compilers), you can deploy it on Linux or Mac OS X if you wish.
You can also use MonoDevelop and Mono Compilers if you decide to code WCF in alternative platforms.
Because not everything is suitable for a simple http request processing cycle. Because SOAP offers features REST does not. Because it hooks into a wide set of encryption, authentication and authorization options. Because what you see as as tremendous problems solve problems for others.
Mono exists to allow .net on other OS's. Mono is not about picking and choosing what to implement based on merit.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I try to be very cautious with this question. There are at least three different web-development frameworks available in Smalltalk. The most prominent seems to be Seaside but there is also AIDA/Web and Iliad.
They seem to be very similiar, but this impresson may be wrong. I wonder who has tried the different tools and can share the pros/cons of the different packages.
A more concrete question would be, do yo know of let's say any software in the bookkeeing area which has choosen to use either of the three (or other) web development frameworks.
Here's one other question. What about maturity and compatiblity. Which framework can one judge as the "most" stable?
99% of my practical experience is with Iliad, so my comparison is primarily about how I got to choose Iliad instead of the others.
Seaside. Tried it first, it is the most known and the first you stumble in. I found it hard to understand (as always, no matter what you use, when it gets to real implementation you always run into issues that fit badly with the general theory), there was little documentation around and the community seemed to care little about telling n00bs how to grow up. I eventually dropped it to check Aida. You find them here: http://seaside.st/ and on IRC at #seaside
Aida. I really liked it, as Janko is extremely patient and supportive. It is large, though. I decided to use it, when I was to start implementation for our project and it was only by chance that I ran into Iliad a few days before starting. You find Aida here: http://www.aidaweb.si/ and on IRC at #Aida
Iliad. The main reason I chose it was that I had just dropped Squeak and switched to gnu-smalltalk. gst seemed to have a lot of ongoing activity on Iliad, so I reckoned I was probably going to get a better assistance with it. It is much smaller as a concept (though it does absolutely everything) and I had very little trouble in getting started and in tweaking it to what I needed for. It also proved to be well managed, as I went thru 3 releases without ever being in trouble with what I had already deployed. You get answers to questions usually in 12-24 hours max, which is fine for me. You find Iliad here: http://www.iliadproject.org/index on IRC issues are usually channeled on the #gnu-smalltalk channel
What we are doing is a GUI for a PostgreSQL database used to manage a large multimedia dictionary, that in turn produces content (among others, for KDE-edu). I have no notion of booking apps in general, so I cannot answer to your question properly.
Yet, speaking as an analyst, a booking app is mostly a DB with an online GUI, so I see no reason why you could not make it. Much will depend on how easily your db can translate into objects. You could use a RDBMS, as we did, and design tables to map objects, or use an OODBMS. Both solutions have pluses and minuses, none of them is going to have an impact on your choice of framework, I'd say.
My suggestion is that you take a month or so in making experiments and see what better fits you. I don't think there is a tool that fits everyone, we are all different and what is easy for me may be hell for someone else (and the other way round, obviously). So try your car before buying it ;)
I would not invest too much time in studying the general theory. Using a smalltalk framework is going to turn upside down the way you make a web app anyway, and your first contact is going to be full of "false friends" you inherit from previous mindsets. Your best asset is definitely going to be "how quick can I grasp what they tell me", and this is largely an individual thing, depending on you and on who you bump into. So I'd really suggest you get your hands dirty BEFORE reading too much theoretical stuff.
These frameworks are all quite different and have different goals. It would be interesting to collaboratively create some kind of comparison.
As an author of Seaside I can provide the key properties of Seaside only:
Seaside makes building web applications feel like composing traditional GUIs: components can be freely composed and reused. Sequences of components are defined using a sequence of Smalltalk statements.
Seaside has a layered architecture, providing you with high-level abstractions (components, control flow, callbacks, HTML generation, JavaScript generation, ...) over low-level concepts (HTTP, Request, Response, URLs, HTML, JavaScript). If you need to, Seaside gives you full access to low-level constructs too.
There are two Seaside books to help you get started: Dynamic Web Development with Seaside and Seaside Tutorial.
Seaside provides a tight integration into various state of the art web technologies: JavaScript (JQuery and JQueryUI), SVG, RSS, HTML5, Comet (Server-Push)
Seaside runs identically on most today's Smalltalk platforms: Pharo Smalltalk, Squeak, GNU Smalltalk, GemStone Smalltalk, VW Smalltalk, VA Smalltalk, and Dolphin Smalltalk. It is supported by all vendors of Smalltalk platforms.
Seaside provides industry proven open-source components for meta-modeling (Magritte) and content management (Pier).
Let me introduce some strengths of Aida/Web too, because as its author it would be hard to me to compare with other two frameworks. Aida strengths are:
RESTfull URLs
MVC support, every domain object can
have its own RESTfull URL, each domain class has its own web presentation class,
Integrated AJAX and Comet
support, you don't see any difference
between a traditional and Ajax
programming anymore,
Tree-like control flow for GUI-like
control flows, without need for
continuations
Building web pages programatically by
composing from components/elements
(no template based)
Scalable in complexity and performance
Integrated security with access
control and users/groups management
Ported to most Smalltalk dialects:
Squeak/Pharo, VisualWorks, Gemstone
GLASS, Dolphin, Smalltalk/X
Prime and most fresh example of Aida at work is this year Smalltalk Google Summer of
Code site.
This is the is a nice example because it was developed it in maybe a week in
total, together with a development of GSoC process in parallel and in
the same time managing that process as an admin. This site is actually
an extended Aida/Scribo CMS, with strong use of so called scriblets,
that is, dynamic web "includes" directly into the content of the site.
That way I was able to very quickly support the new ideas which come
during the evolving GSoC process.
Well, Suixo uses Seaside. Take a look at the GSoC projects we defined. Its more ERP than bookkeeping, and currently focused on healthcare.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Interface Builder can be used for basic dependency injection in a Cocoa app, but is anyone aware of more complete dependency injection frameworks for Objective-C/Cocoa for when you don't want to instantiate objects in a NIB file?
Edit
To clarify, I recognize that IB can be used for basic DI, but I'm looking for a framework with more complete functionality, including separate production and testing configurations, along the lines of Groovy or Springs.
objection by AtomicObject. It is molded in the image of Guice.
I'll go out on a limb and speak on this. Dependency injection as described by the top answer doesn't address the core issue that those seeking to use it are having. We'd like a means of development where component A does not directly instantiate or reference component B. Component A is bound by protocol to component B and is not referenced at all by component A. This allows component B to be replaced at anytime without ever touching component A. I down voted but I will research your references as it seems there are a few who agree with you. I'm not trying to debate, just looking to learn. I'd like to understand more about the "nope you don't need to do that" approach.
I think you'll find that you don't need it in late-binding languages like Objective C, Ruby, Lisp and so on. Like Jamis' revelation that he was going down an overly complex path when he tried to build needle, a DI framework for Ruby- Net::SSH revisited.
Here are some links that will hopefully give you some sample code to do similar things in Objective C. With categories you can essentially change any class's behavior at runtime. See Mac Developer Tips – Objective-C: Categories and the Cocoa API docs on categories. Essentially you don't need some central place to ask for "the thing that does x" that is configurable, because you can just instantiate TheThingThatDoesX directly and if something else needs to change/hook into that behavior it can use categories.
Typhoon
Almost one year ago, I released: https://github.com/typhoon-framework/Typhoon
The Typhoon-website lists the key features. A quick summary:
Non-invasive. No macros or XML required. Uses a powerful Objective-C runtime approach.
Makes it easy to have multiple configurations of the same base-class or protocol.
No magic strings - supports IDE refactoring, code-completion and compile-time checking.
Supports injection of view controllers and storyboard integration.
Supports both initializer and property injection, plus life-cycle management.
Powerful memory management features. Provides pre-configured objects, without the memory overhead of singletons.
Excellent support for circular dependencies.
Lean. It has a very low footprint, so is appropriate for CPU and memory constrained devices.
Battle-tested - used in all kinds of Appstore-featured apps
An internationally distributed core team (we even monitor StackOverflow), so support for any of your questions are never far away :)
API Docs and sample app
API docs: http://www.typhoonframework.org/docs/latest/api/
We have a nice sample app: https://github.com/jasperblues/Typhoon-example
Quality Control:
We also maintain a robust quality control system.
Every commit triggers a series of regression tests
We maintain high test coverage.
You don't have to instantiate the object in the NIB file. If you set the File's Owner to your object's class and then link things in the view/window/whatever up to that, you can set your object as the owner at runtime by loading the nib file manually. That way you can have a dynamic instance of an object that still gets dependencies injected properly.
What about dependecy injection implementation at Objective-IOC
What about ObjectivePim?
ObjectivePim
I’ve written a very simple DI container, the code is on GitHub. It can only do the bare basics, ie. discover the dependencies of an object and satisfy them using other given objects. I have found that to be usable in real-world applications, the code is very simple and it’s fun to hack with.
Has any looked at the Associative References feature of Mac OS X 10.6?
I believe with this it would be possible to build or already have something similar to DI.
As far as I have seen however any reference that is needed in an object has to be fetched manually using objc_getAssociatedObject().
Manfred
Interface Builder does not do ANY dependency injection. It does not need to. Interface Builder serializes objects. When a nib is "awoken" (aka opened), there are no "dependencies" to resolve -- there are just properties to set. Very, very simple. Opening a nib relies solely on the NSCoding protocol and key-value coding.
Dependency injection, pretty much a make-work project at the best of times, or at best a generalized glue layer between components designed independently, is of no use in well written Objective-C code. You are asking for a tool that you don't need.
In Objective-C, software that requires an anonymous service declares a Protocol. Services then adopt this protocol. Clients load services as dynamic plug-ins. On the other hand, if the server was written prior to the client, it is simply a matter of writing a new plug-in which adapts the existing interface to the protocol. This is less work, and more straightforward than trying to define an intermediate data-driven system for "discovering" (please) an interface at runtime.
Is it not obvious to everyone that the big secret of DI is just that it's a way to write code in XML instead of in the native language? I'd really like to hear a good argument as to how XML is somehow a better programming language than a real programming language. It doesn't make any sense.
I work with Spring all day and I've checked Groovy. I'm by no means an XCode/Cocoa expert, but IB does only some dependency injection, which Groovy doesn't even really claims to be doing.
I reckon you are not looking for DI, but rather for a well compiled set of integrated libraries which saves you from typing a lot of code which other people also have typed. I think there are no Spring like frameworks for Cocoa because for some reason people tend to see "Open Source" as "not platform dependant" and therefore Cocoa is a bit left out in the cold.
Depending on your needs though, there are some nice free open source libraries available for Cocoa, all listed on CocoaDev in a nice list.
I know it isn't Spring, but I hope it helps.
DI is a property of a runtime execution enviroment requiring dynamic binding. I'm very new to Obj-C and Cocoa so I may speak out of turn. Unless I'm missing something, I don't see how one could implement DI except by interpreting Obj C rather than compiling it, or by modifying the runtime environment.
I suspect that the DI like behaviour of IB is because there is a domain specific runtime environment associated with apps that are built with it.
I'm happy to be corrected though.
Categories appear to be an implementation of mixin's, allowing dynamic dispatch of methods to a delegate. Rather cool and similar to Java's interface concept, thought the details differ and from the following, I can't see if constants can be defined in a category, though member fields cannot.
objective-c categories