I need to implement a proxy pattern for flex action script. The source object contains 40-50 methods, and may keep increasing, so I hope I could avoid implementing individual methods in the source object.
I remember in java, I could use reflection to centralized all the proxy calls, is there any similar mechanism in Flex Action Script?
Thanks.
I'm not sure what exactly you want to accomplish but there is a handy AVM bytecode library from AS3Commons that allows to create classes on runtime. There is example how to generate dynamic proxy.
Related
I've been looking into scaling Meteor, and had an idea by using the Meteor Cluster package;
Create a super-service*, which the user connects to, containing general core packages to be used by every micro-service (api, app, salesSite, etc. would make use of its package),
The super-service then routes to the appropriate micro-service (e.g., the app), providing it with the functionality of its own packages.
(* - as in super- and sub-, not that it's awesome... I mean it is but...)
The idea being that I can cascade each service as a superset of the super-service. This would also allow me to cleverly inherit functionality for other services in a cascading service style. E.g.,
unauthedApp > guestApp > userApp > modApp > adminApp,
for the application, where the functionality of the previous service are inherited to the preceding service (e.g., the further right along that chain, the more extra functionality is added and inherited).
Is this possible?
EDIT: If possible, is there a provided example of how to implement such a pattern using micro-services?
[[[[[ BIG EDIT #2: ]]]]]
Think I'm trying to make a solution fit the problem, so let me re-explain so this question can be answered based on the issue rather than the solution I'm trying to implement.
Basically, I want to "inherit" (for lack of a better word) the packages depended on needed functionality, so that no code is unnecessarily sent through the wire.
So starting with the core packages, which has libraries I want all of my services to have, I then want to further "add" the functionality as needed. Then I want to add page packages if serving a page-based service (instead of, say, the API service, which doesn't render pages), then the appropriate role-based page packages, etc., until the most specific packages are added.
My thought was that I could make the services chain in such a way that I could traverse through from the most generic to most specific service, and that would finally end with a composition of packages from multiple services. So, for e.g., the guestApp, that might be the core packages + generic page packages + generic app packages + unauthApp packages + guestApp packages, so no unneccessary packages are added.
Also with this imaginary pattern I'm describing, I don't need to add all my core packages to each microservice - I can deal with them all within the core package right at the top of the package traversal I've discussed above and not have to worry about forgetting to add the packages to the "inherited" packages.
Hope my reasoning here makes sense, and I hope you guys know of a best practice for doing this. Thank you!
Short answer:
Yes! That's a good use to a microservice architecture.
Long answer:
Microservices don't necessarily provide you an inheritence mechanism as in OOP. You should consider microservices as independent "functions" which take in an input and respond with an output/action. Any microservice can depend on another to complete its own task.
And then, you "compose" necessary microservices in order to achieve the final output/action.
You can have one or few web facing "frontend" services that use a mix of few other backend microservices whose ports are not open to the public network.
The drawback with a microservice would be its "minimum footprint". The idea with microservices is around some main benefits:
Separate core services so that they can be "maintained" independently
Separate core services so that they can be "replaced" independently
Separate core services so that they can be "scaled" independently
But then, each microservice, being a node/meteor app, will have its minimum cpu/ram footprint even when they are just idle and waiting for a connection.
Furthermore, managing a single monolithic app, or just a few "largish" services is much easier, from a devops standpoint, than managing tens of individual deployments.
So with all engineering decisions, the right answer would imply some kind of "balance".
Edit: reference to inheritence
As per the OP's comment, the microservices can indeed be referenced from a parent code as either functions or classes and be composed (functions) or inherited from (classes) because after all the underlying functionality are DDP endpoints.
If you are using the cluster package from meteorhacks
// create a connection to your microservice
var someService = Cluster.discoverConnection("someService");
// call a normal meteor method from that service
var resultFromSomeService = someService.call("someMethodFromSomeService");
So as with any piece of javascript code, you can wrap the above piece of code in a function or a class with its constructor and all and inherit from it, exposing its interfaces as you desire.
I am learning Symfony2 and I find the dependency injection stuff and service container interesting.
But I want to know if I should make all my logic in the service container and then call it form controller or I could use the old way ( make classes and instantiate them when I need ) ?
Here's what says the official documentation on this topic,
"The advantage of thinking about "services" is that you begin to think about separating each piece of functionality in your application into a series of services. Since each service does just one job, you can easily access each service and use its functionality wherever you need it. Each service can also be more easily tested and configured since it's separated from the other functionality in your application. This idea is called service-oriented architecture and is not unique to Symfony2 or even PHP. Structuring your application around a set of independent service classes is a well-known and trusted object-oriented best-practice. These skills are key to being a good developer in almost any language."
Put another way, Turn the common logic (used globaly in your application) into services is a good practice.
From my point of view, the role of the container is to make available to the whole application all the common logic.
It acts as a substitute to all global arrays ($_REQUEST, $_GLOBALS, etc...), to global variables, global constants (as opposed to class constants, which remain useful), global functions and all such things that makes PHP a rather messy language. It aims at making PHP the full OOP language it wants to be.
It incites one to avoid procedural programming that PHP still allows, and that is good.
In short, you can still instanciate and use classes the usual way. But whenever you spot two pieces of code alike, or using a same logic, or reusing the same information, that generally means you want to use the service container to help reusing the code.
I would like to implement the MVC pattern to an existing Flex project. I want to separate out the controllers and models from the views. They currently all live together in large mxml files.
My question is, should httpservice requests be in the model or the controller? What sort of advantages/disadvantages would there be to either?
I normally try to abstract any service request into a Command call (execute, result, fault) which gets the service it needs to called injected in (which can be a good idea to abstract even more and be a service delegate).
There's a good example of how to use short lives command objects in Parsley's dev manual (one of the more popular frameworks).
I would rather approach the services as something totally different - an MVCS, not just MVC. You should check the Introduction to Flex Application's Architecture I wrote in my blog.
I looked at httpservice, and it seems to me that, while the service itself might reside in a repository or Service Layer (between the controller and the model), using the service involves references to UI elements such as DataGrid. So the implementation of that service probably would occur in the controller, or even in a ViewModel object.
What are the benefits of Spring Actionscript considering Dynamic Proxies are not possible in the current version of Actionscript and Reflection is quite limited.
So for example I could specify my object creation in an XML application context, but why would I do that when I can simply specify that in code, and hence take advantage of static type checking etc.
It is by no means my intent to belittle the work done on Spring Actionscript but more to find an application for it in my projects.
Besides XML configuration, Spring ActionScript also supports MXML configuration. The type of config (XML, MXML) depends on the use cases your application needs to support. For the reasons you mention, it makes perfect sense to configure most of the context in MXML, but I would encourage you to externalize the config of service endpoints in every case.
In a past project we opted for XML config since the configuration was generated at runtime when a user logged on to the application. Depending on the user credentials, different endpoints and various different settings were used. We could not have done this elegantly with static MXML configs.
Both config types have their strengths and weaknesses, and it's up to you to decide what type you want to use. I think we could even support a mixture of MXML and XML quite easily actually if that would make sense. As soon as we have Dynamic Proxies and class loading, XML config will make a lot more sense.
I would agree with Sean in the general sense that trying to force Flex inside of the Java box is generally a bad idea. As many similarities as there are, Flex is not Java.
That being said, there are plenty of reasons why you might want to have some of your configuration in an external XML file, not the least of which is in the use case of configuring your service destinations and endpoints, where you may have a need to be able to change the endpoint URI without having to recompile your application.
There are several projects available that are simply misguided ports of philosophies from other platforms. Whenever starting in on a new platform, I think the best thing to do is figure out how people are effectively developing and go from there.
I say all of that because I think all of the java-esque frameworks for flex/flash leave you worse off than you started. You do need dependency injection, but there are good as3/mxml-friendly frameworks for that (Mate, Swiz). There is absolutely no point in using xml when you can use mxml, which is strongly typed.
With NInject (preferably 2.0), what options do we have wrt wiring up our object dependencies in a web application?
Can they be defined in an XML configuration file?
Or does it have to be done via code?
There is an extension for xml based configuration: https://github.com/ninject/ninject.extensions.xml
You can do a lot more powerful binding in code though.
Ninject doesn't have XML configuration, sorry but I can't provide a direct link (cos their site has flash elements), but here is a quotation from ninject.org:
Free yourself from XML
Most other .NET dependency injection
frameworks are designed around the use
of XML to declare type bindings.
Rather than forcing you to write
cumbersome and error-prone text,
Ninject arms you with a fluent
interface, which lets you connect the
pieces of your application using
full-fledged code. This means you can
take advantage of the features of the
IDE and compiler, like code completion
and type-safety.
The problem I see with defining bindings in the code only is that you have to add reference to the dll.
You cannot change the binding without adding reference to new dll (removing reference to old one), change code and recompile.
If we had xml config I wouldn't need reference at all, and wouldn't have to recompile.
Right now I have MVC app that is using DI to pass repositories to Controllers. Nothing else then Ninject code for adding bindings uses the concrete implementations of repositories. And still I need to add reference to dll containing the implementations. For only one line of code!
Or maybe there is a possibility to achieve this using Ninject?
What are you looking to achieve? What sort of stuff are you looking to configure? Dynamically selecting a Strategy ? Passing in Port numbers? You could offer a lot more information as to what you're thinking in order to get a better answer [that you can acccept :P].
You need to split the concerns of:
known object wiring (DI)
configuration - generally you'll want to split those into small focused subsets e.g. Strongly Typed config elements vs having a global pool of settings in a big pile mishmashed together a la appSettings
plugins / unknown object wiring (MEF?)
In the first pool, doing it in Code is just the right way and I cant think of any advantage XML would give, esp. in the context of strong names etc.