Suppose I have two ViewModels and a Screen Conductor in my application.
public class ShellViewModel : Conductor<IScreen>, IShell
{
public ShellViewModel()
{
ShowConnectionScreen();
}
public void ShowConnectionScreen()
{
ActivateItem(new ConnectionViewModel());
}
public void ShowSetupScreen()
{
ActivateItem(new SetupViewModel());
}
}
The first ViewModel is displayed on start up, and contains some setup information and a Connect button which initializes a connect to somewhere.
If the connection is established successfully, then I would like the first ViewModel to close and the second ViewModel to display some information about the connection. If it fails, the first ViewModel should simply display that, and allow the user to attempt connection once again.
Thus I need the actual connection object to be passed from the first ViewModel to the second ViewModel and the Screen Conductor to change viewmodels on success.
How can this be achieved in Caliburn.Micro?
To illustrate #mvermef's comment:
use a common type between the 3 class objects, obviously create this type in question
This would be the connection object that the first view model populates and is used by the second view model.
public class Connection {
// props, methods, etc...
}
and pass it either in constructor or make it a property of all 3 classes
public class ShellViewModel : Conductor<IScreen>, IShell
{
public Connection Connection { get; set; }
public ShellViewModel()
{
Connection = new Connection();
ShowConnectionScreen();
}
public void ShowConnectionScreen()
{
ActivateItem(new ConnectionViewModel(Connection));
}
public void ShowSetupScreen()
{
ActivateItem(new SetupViewModel(Connection));
}
}
Do what you want with the Connection object inside ConnectionViewModel
public class ConnectionViewModel : Screen
{
public Connection Connection { get; set; }
// establish connection
// can call (Parent as IConductor).DeactivateItem(this)
// after connection is established
}
You can notify the parent conductor if a connection is established by (1) registering through ConnectionViewModel's Deactivated event (assuming you subclass Screen). Or (2) you can use EventAggregator to fire an event if the connection is established and having ShellViewModel implement IHandle. You can then call ShowSetupScreen() inside the Deactivated event handler or the Handle method.
Option 1:
// ShellViewModel
public void ShowConnectionScreen()
{
var connectionVM = new ConnectionViewModel();
connectionVM.Deactivated += ConnectionViewModel_Deactivated;
ActivateItem();
}
private void Scheduler_Deactivated1(object sender, DeactivationEventArgs e)
{
ShowSetupScreen();
}
Option 2:
public class ShellViewModel : Conductor<IScreen>,
IShell, IHandle<string>
{
private readonly IEventAggregator _eventAggregator;
public ShellViewModel(IEventAggregator eventAggregator)
{
_eventAggregator = eventAggregator;
_eventAggregator.Subscribe(this);
}
// from IHandle<string>. you can create a custom object to represent this event
public void Handle(string message)
{
if (message.Equals("connection.successful"))
{
ShowSetupScreen();
}
}
}
public class ConnectionViewModel : Screen
{
private readonly IEventAggregator _eventAggregator;
public ConnectionViewModel(IEventAggregator eventAggregator)
{
_eventAggregator = eventAggregator;
}
// call _eventAggregator.PublishOnUIThread("connection.successful");
}
Related
I have the below aggregate which contains an aggregate member.
#Aggregate
public class CpaAggregate {
#AggregateIdentifier
private String externalId;
#AggregateMember
private Entity entity;
public CpaAggregate() {
}
#CommandHandler
public CpaAggregate(CreateCpaCommand cmd) {
AggregateLifecycle.apply(new CpaCreatedEvent(...));
}
#EventSourcingHandler
protected void on(CpaCreatedEvent evt) {
....
}
}
public class Entity {
#EntityId
private String entityId;
private Set<Identifier> identifiers = new HashSet<>();
public Entity() {
}
#EventSourcingHandler
public void on(IdentifiantUpdatedEvent evt) {
...
}
}
public class Laboratory extends Entity {
private OperatingSystem operatingSystem;
public Laboratory() {
}
#CommandHandler
public void handle(UpdateIdentifierLABCommand cmd) {
AggregateLifecycle.apply(new IdentifiantUpdatedEvent(....));
}
}
.
commandGateway.sendAndWait(new UpdateIdentifierLABCommand(...));
When i send a command to update an identifier of entity of type laboratory, i get this error
org.axonframework.commandhandling.NoHandlerForCommandException: No
handler was subscribed to command [UpdateIdentifierLABCommand]
I would model your CpaAggregate slightly differently, Aymen.
Instead of using the generic Entity aggregate member, I'd go for more specific entities like the Laboratory instance.
This is, for one, a lot more clear modeling-wise, as the model structure becomes clearer. Secondly, Axon Framework will move up into parent class for specifics. So, you can still have common information in an Entity class, like entity identifiers, command handlers, and event sourcing handlers.
I would thus adjust it like so:
#Aggregate
public class CpaAggregate {
#AggregateIdentifier
private String externalId;
#AggregateMember
private Laboratory laboratory;
public CpaAggregate() {
}
#CommandHandler
public CpaAggregate(CreateCpaCommand cmd) {
AggregateLifecycle.apply(new CpaCreatedEvent(...));
}
#EventSourcingHandler
protected void on(CpaCreatedEvent evt) {
....
}
}
This should ensure Axon Framework spots the command handler inside the aggregate member too, by the way.
When i try to run the project, i am getting this kind of error: "System.NullReferenceException: Object reference not set to an instance of an object"
pointing in this code:
sqliteconnection = DependencyService.Get().GetConnection();
This is my Class for DB actions:
namespace DevoApp.DevoAppFinal.Helpers
{
public class DatabaseHelper
{
static SQLiteConnection sqliteconnection;
public const string DbFileName = "Devotion.db";
public DatabaseHelper()
{
sqliteconnection = DependencyService.Get<ISQLite>().GetConnection();
sqliteconnection.CreateTable<Devotion>();
}
// Get All Contact data
public List<Devotion> GetAllDevotionsData()
{
return (from data in sqliteconnection.Table<Devotion>() select data).ToList();
}
//Get Specific Contact data
public Devotion GetDevotionData(int id)
{
return sqliteconnection.Table<Devotion>().FirstOrDefault(t => t.devotionalId == id);
}
// Delete all Contacts Data
public void DeleteAllDevotions()
{
sqliteconnection.DeleteAll<Devotion>();
}
// Delete Specific Contact
public void DeleteDevotion(int id)
{
sqliteconnection.Delete<Devotion>(id);
}
// Insert new Contact to DB
public void InsertDevotion(Devotion contact)
{
sqliteconnection.Insert(contact);
}
// Update Contact Data
public void UpdateDevotion(Devotion contact)
{
sqliteconnection.Update(contact);
}
}
}
When using the DependencyService, you have to implement the interface in each targeted platform project.
In this case, you should have the ISQLite interface implemented on the platforms you're targeting, i.e. iOS and Android.
To make Xamarin find it at runtime, you will have to register the implementation with the Dependency attribute above the namespace. Observe the following example based on a few assumptions of your project.
In your shared library you have declared the interface:
public interface ISQLite
{
// Members here
}
Nothing fancy going on there. Then for each platform, you want to run the app on, do something like this:
[assembly: Xamarin.Forms.Dependency (typeof (SQLiteImplementation_iOS))]
namespace DevoApp.DevoAppFinal.iOS
{
public class SQLiteImplementation_iOS : ISQLite
{
// ... Your code
}
}
From the error, it looks like you forgot to add the attribute
Im using asp.net core. Here is the basic way to use model with controller.
public class BookController : Controller
{
private readonly ApplicationDbContext _context { get; set; }
public BookController(ApplicationDbContext context)
{
_context = context;
}
public IActionResult Create(Book model)
{
// adding new model
}
public IActionResult Edit(Book model)
{
// modifying the model
}
public IActionResult Delete(Book model)
{
// removing the model
}
}
My question: when shall/should I implement the code inside the controller? When shall/should I implement it in another class?
Something like this:
public interface IBook
{
int Add(Book book);
int Update(Book book);
int Remove(Book book);
}
public class BookData : IBook
{
private readonly ApplicationDbContext _context { get; set; }
BookData(ApplicationDbContext context)
{
_context = context
}
public int Add(Book model)
{
// ...
return _context.SaveChanges();
}
// other implements...
}
Then, calling it inside controller:
public IActionResult Create(Book model)
{
var bookData = new BookData(_context);
int result = bookData.Add(model);
// ...
}
For the interface, I think it may be useful for the case: I have many controllers that require same action/method names.
Example: MessageController requires 3 actions/methods at least (Create/Add, Edit/Update, Delete/Remove). It's same to NotificationController class, CommentController class...
So, the interface can be improved to:
public interface IMyService<T> where T : class
{
int Add(T model);
int Update(T model);
int Remove(T model);
}
public class MyService<T> : IMyService<T> where T : class
{
private readonly ApplicationDbContext _context { get; set; }
public MyService(ApplicationDbContext context)
{
_context = context;
}
public int Add(T model)
{
Type type = typeof(model);
if (type == typeof(Book))
{
// adding new book model
}
else if (type == typeof(Comment))
{
// adding new comment model
}
// ...
return -1;
}
// other implements...
}
Do I misunderstand something?
If I read it correctly with data classes you actually means repository (which is an abstraction over the persistence layer). You should always encapsulate persistence logic behind a class (be it via repository pattern, command/query pattern or request handler) and use it instead of directly using the context in your service classes.
That being said, you can directly inject your BookData to your controller instead of the ApplicationDbContext. One thing you should consider you lose in your current implementation is the Unit of Work pattern. Right now, every add will instantly persist the data.
This may not be what you want, so you should move the _context.SaveChanges(); outside of the Add/Remove/Update methods and call it explicitly. This allows you to insert i.e. 10 records and if one of them fails, nothing will be persisted to the database.
But if you call _context.SaveChanges(); after each insert and you get an error in the 8th (of 10) records, then 7 get persisted and 3 will be missing and you get inconsistent data.
Controller shouldn't contain any logic at all, only do short validation of the input model (ModelState.IsValid check) and if its okay, call the services which do all the logic and report the result back to the user. Only in very simple tutorials and guides logic is put into the controller action for reasons of simplicity. In real world applications you should never do that. Controllers are much harder to unit test than service classes.
Is there a way to do this using DI? I tried IScopedInstance<Controller> but this gives me null. Poked around aspnet's source code but didn't win. Any ideas?
I have a controller that accepts different IPaymentMethods. The IPaymentMethod can be a ViewComponent that can render Views. If the IPaymentMethod is a ViewComponent, I want it to use MVC's built-in model binding on post back.
public class XController : Controller
{
// ctor, props, ...
public IActionResult Checkout()
{
return View(new Model
{
PaymentMethodId = 1,
PaymentMethodType = typeof(MyPaymentMethod) // The razor file will use this type to render it as a ViewComponent
});
}
[HttpPost]
public IActionResult Checkout(Model model)
{
var paymentMethod = _paymentService.GetPaymentMethodById(model.PaymentMethodId);
paymentMethod.ProcessPayment();
// ..
}
}
This is where I need the controller to be injected. I wanted to make use of the built-in MVC validation and model binding.
public class MyPaymentMethod : IPaymentMethod
{
private Controller _currentController;
public MyPaymentMethod(IScopedInstance<Controller> controller)
{
_currentController = controller.Value;
}
public void ProcessPayment()
{
var model = new PaymentModel();
_currentController.TryUpdateModel(model, typeof(PaymentModel), null);
if (!_currentController.ModelState.IsValid)
{
return; // or exception
}
// Process Payment using model
}
public Task<IViewComponentResult> InvokeAsync()
{
// returns View
}
}
public interface IPaymentMethod
{
void ProcessPayment();
}
Since the model instance is required in the ProcessPayment method, why not simply pass it as a parameter?
[HttpPost]
public IActionResult Checkout(PaymentModel model)
{
var paymentMethod = _paymentService.GetPaymentMethodById(model.PaymentMethodId);
if (!ModelState.IsValid)
{
return; // or exception
}
paymentMethod.ProcessPayment(model);
// ..
}
public void ProcessPayment(PaymentModel model)
{
// Process Payment using model
}
Your service is taking on responsibilities that belong to the controller - namely checking ModelState.IsValid.
public interface IPaymentMethod
{
void ProcessPayment(PaymentModel model);
}
You may wish to also pass just the properties that are needed from the payment model, or you may wish to make an IPaymentModel interface to decouple your model from your PaymentService. In that case, your IPaymentModel would go into a shared layer.
public interface IPaymentMethod
{
void ProcessPayment(IPaymentModel model);
}
This no longer works with beta7
At this time of writing (beta6), this probably isn't supported and there is a good reason for it: Controllers in ASP.NET 5 does not need to inherit from the Controller class. I have, however, found a way for this to work using ActionFilters.
public class ScopeControllerActionFilterAttribute : ActionFilterAttribute
{
private readonly IScopedInstance<Controller> _controller;
public ScopeControllerActionFilterAttribute(IScopedInstance<Controller> controller)
{
_controller = controller;
}
public override void OnActionExecuting(ActionExecutingContext context)
{
if (_controller.Value == null)
{
_controller.Value = context.Controller as Controller;
}
}
}
Note that depending on the stage of the http request lifecycle, the Value of IScopedInstance<Controller> may still be empty.
I am using unity, entity framework 4 with POCO classes, repository pattern for DAL and services for Business Logic control.
I also want to use Unit of Work so I can package together CRUD operations which I perform on different services and then commit them all together.
My question is what would be the proper way to inject the Unit Of Work mechanism into my application using Microsoft Unity?
I understand that I can put the IUnitOfWork together with the repository on the constructor of the proper service and then if Unity mapping is specified it would auto initiate the proper instances, but this way I do not pass the global unit of work but rather create a new instance on each level, which can't be a smart way to do it (actually the repository is initiated even before the service).
What am I missing? (Attached is constructor code as I wrote it now of service and its repository).
U also understand that I can use Unity's ParameterOverrides method to take some global instance of Unit of Work (lets say from my aspx.cs file) and pass it into the service and then into the repository. But it seems a bit lame. Is this my only option?
Thanks
public class GenericRepository<T> : IUnitOfWorkRepository, IGenericRepository<T> where T : BaseEntity, IAggregateRoot
{
private IUnitOfWork _uow;
/// <summary>
/// Returns the active object context
/// </summary>
private ObjectContext ObjectContext
{
get
{
return ObjectContextManager.GetObjectContext();
}
}
public GenericRepository(IUnitOfWork uow)
{
_uow = uow;
}
//blahhhh...
public void Add(T entity)
{
_uow.RegisterNew(entity, this);
}
public void Delete(T entity)
{
_uow.RegisterRemoved(entity, this);
}
//.....blah blah....
public void PersistCreationOf(IAggregateRoot entity)
{
this.ObjectContext.AddObject(GetEntitySetName(), entity);
}
public void PersistUpdateOf(IAggregateRoot entity)
{
// Do nothing as EF tracks changes
}
public void PersistDeletionOf(IAggregateRoot entity)
{
this.ObjectContext.DeleteObject(entity);
}
}
public class CategoryRepository : GenericRepository<XComSolutions.FB.Domain.Model.Entities.Category>, ICategoryRepository
{
public CategoryRepository(IUnitOfWork uow)
: base(uow)
{ }
}
public class CategoryService : ICategoryService
{
public int myID {get; set;}
private ICategoryRepository _categoryRepository;
private IUnitOfWork _uow;
public CategoryService(ICategoryRepository categoryRepository,
IUnitOfWork uow)
{
_categoryRepository = categoryRepository;
_uow = uow;
}
public List<Category> GetAll()
{
return _categoryRepository.GetAll();
}
}
Define an IUnitOfWorkFactory and inject that in your services:
public class Service
{
private readonly IUnitOfWorkFactory factory;
public Service(IUnitOfWorkFactory factory)
{
this.factory = factory;
}
public void DoOperation()
{
using (UnitOfWork context = this.factory.CreateNew())
{
this.DoSomeStuff(context);
this.DoMoreStuff(context);
context.SubmitChanges();
}
}
}
What I think you need to do is to define unit of work factory. You register this factory with your DI container and you resolve for this factory every time you need your unit of work. Then you get unit of work from the factory, work with it and let it go. You often will see that you need your unit of work within a scope of single method or single class. This article discuss Unit of Work pattern in connection with Entity Framework: http://msdn.microsoft.com/en-us/magazine/dd882510.aspx