Is it possible to define several application objects in Backbone.Marionette Application? What is the best practise for creating modular application - to establish a set of application objects with distinct names, or describe specific functionality in modules extended from Marionette.Module?
Marionette has the concept of application modules baked in.
https://github.com/marionettejs/backbone.marionette/blob/master/docs/marionette.application.module.md
MyApp = new Backbone.Marionette.Application();
MyApp.module("Foo", function(){
// module code goes here
});
MyApp.start();
Related
I am currently attempting to migrate a current Xamarin Forms 2.0 application to make use of the new Xamarin Shell facilities (in particular the navigation). This existing application is based on a MVP pattern which means that in my Presenter layer i inject instances of my pages to allow the presenter to wire up events on the pages.
I am struggling at the moment in achieving this this Shell as from what I understand it is in control of creating instances of the pages and does not use the IoC I am currently using (which happens to be Unity).
Is there a way that I can configure the Shell to use my IoC container to resolve the page instances when it is creating them rather than creating them itself.
Any help on this would be appreciated.
I would like to use Autofac IOC container in my bot application (based on BotFramework).
I can see that framework itself already uses it.
But I can't figure out how to do it gracefully... I don't want to resolve my components on every post invocation (it will slow down my post method execution).
I appreciate if you share code snippets with your solutions.
Thanks in advance!
You can use the Autofac container being used in the framework in the Global.asax and perform your own registrations.
The key code pieces are:
var builder = new ContainerBuilder();
// perform your registrations on the builder
// update the container being used by the framework
builder.Update(Conversation.Container);
For a real implementation of this, you could take a look to the ContosoFlowers sample where you will see that a Module is used to register the application specific components. Here is the Global.asax and here the actual module.
I'm developing an client-server application. In this application, Model classes are supposed to be in Server side whereas Controller and Views will be in Client side. I'm trying out Griffon to build User Interfaces. As Griffon implements MVC patterns and there is a convention of having Models, Views and Controllers in directory structure like app/models, app/views and app/controllers respectively. Also I'm using Spring to provide remoting service.
Now, my problem/confusion here about Griffon and Spring integration is that, Can I have Model classes in remote Server and still be in convention of Griffon?
What is the pattern to develop Client-Server application using Griffon and Spring?
Yes, you can have Model classes on the server however the UI still requires an object on its side in order to bind properties to UI components. This usually means you must have a "shallow" Model on the client side that reflects as many properties as needed. There are several remoting http://artifacts.griffon-framework.org/tags/plugin/remoting plugins that can be used. You can also try http://open-dolphin.org/dolphin_website/Home.html as it hides away the remoting layer and you only work with observable Models.
I have spring MVC application where in I will be loading the multiple components (jars) in run time. Each component can create its own topic/queue. I also need to build a special integration route (including channel and other components) when I load the new component. And delete the route when I remove the component. I was thinking dynamically generating a spring xml file with routes and load into container. Is this possible or do I have any better alternatives
The dynamic-ftp sample uses that technique...
It uses the Spring 3 environment feature to pass in properties to each instance of the context. If these contexts need access to elements (channels etc) in the main context, you can make the dynamic contexts a child of it. That is discussed here...
I've been using ASP.net MVC for about two years now and I'm still learning the best way to structure an application.
I wanted to throw out these ideas that I've gathered and see if they are "acceptable" ways in the community to design MVC applications.
Here is my basic layout:
DataAccess Project - Contains all repository classes, LINQ-to-SQL data contexts, Filters, and custom business objects for non-MS SQL db repositories (that LINQ-to-SQL doesn't create). The repositories typically only have basic CRUD for the object they're managing.
Service Project - Contains service classes that perform business logic. They take orders from the Controllers and tell the repositories what to do.
UI Project - Contains view models and some wrappers around things like the ConfigurationManager (for unit testing).
Main MVC Project - Contains controllers and views, along with javascript and css.
Does this seem like a good way to structure ASP.NET MVC 2 applications? Any other ideas or suggestions?
Are view models used for all output to views and input from views?
I'm leaning down the path of making view models for each business object that needs to display data in the view and making them basic classes with a bunch of properties that are all strings. This makes dealing with the views pretty easy. The service layer then needs to manage mapping properties from the view model to the business object. This is a source of some of my confusion because most of the examples I've seen on MVC/MVC2 do not use a view model unless you need something like a combo box.
If you use MVC 2's new model validation, would you then validate the viewmodel object and not have to worry about putting the validation attributes on the business objects?
How do you unit test this type of validation or should I not unit test that validation messages are returned?
Thanks!
Interesting.
One thing I do differently is that I split off my DataAccess project from my Domain project. The domain project still contains all the interfaces for my repositories but my DataAccess project contains all the concrete implementations of them.
You don't want stuff like DataContext leaking into your domain project. Following the onion architecture your domain shouldn't have any dependencies on external infrastructure... I would consider DataAccess to have that because it's directly tied to a database.
Splitting them off means that my domain doesn't have a dependency on any ORM or database, so I can swap them out easily if need be.
Cheers,
Charles
Ps. What does your project dependency look like? I've been wondering where to put my ViewModels. Maybe a separate UI project is a good idea, but I'm not entirely sure how that would work. How do they flow through the different project tiers of your application?