Recently I saw this document that specify how great is Caliburn(Not really it compares it to the micro framework, and thats enough).
I'm working with Caliburn for more than a year and don't know many things about it.
So maybe someone can explain the following(Some of it I can understand but have no iea about the relation to caliburn):
Validation abstraction
module framework
ExpressionTree-Based runtime delegate generation
ViewModelFactory
ShellFramework
I'm working with V1.1 so if something is new in 2.0, just say it belong to the new version I'll learn it probably in the future.
The validation abstraction is aimed to plug a validation infrastructure in ViewModels.
Caliburn's DefaultValidator uses System.ComponentModel.DataAnnotations, but an adapter for Fluent Validation is also available.
While the validation could be used directly from application code, it is used by the framework mainly in the AOP validation behavior, which provides an automatic IDataErrorInfo implementation for models.
If your models already implement IDataErrorInfo, Caliburn is able to hook the validation (as a part of conventional binding process) leveraging plain WPF binding.
Yet, implementing IDataErrorInfo manually is boring and likely to lead to hardly mantainable code, so the AOP [ValidateAttribute] was introduced.
To enable it, you have to configure your container to use the available proxy factory (which is based upon Castle.DynamicProxy):
myContainerAdapter
.WithProxyFactory<Caliburn.DynamicProxy.DynamicProxyFactory>()
This instructs the container adapter to inspect behaviors attribute applied on the ViewModels (and other components) pulled from the container, and to create a subclass of them implementing the specified behavior.
The [Validate] behavior implementation just delegates 'IDataErrorInfo' calls to the actual IValidator service.
Module framework is used by Caliburn itself to manage configuration and initialization of its own modules. It could also be used to create independent application modules: Caliburn will take care of discovering them (if their assemblies are registered in IAssemblySource) an drive their initialization;
Caliburn doesn't use reflection to invoke action, but builds delegates on the fly leveraging Expression Trees to create a compiled lambda;
The ViewModelFactory service is used by Caliburn to abstract the creation of VM, either by type or by Subject handled;
ShellFramework contains a set of facility useful to build most applications; it includes some custom IResult (along with fluent-style static methods to create them) and some pre-built ViewModels (Menus and Question/Message dialog) to accomplish common application tasks.
Related
I am working in an asp.net mvc application that uses Ninject for DI. I have been attempting to implement Ninject Interception for logging, following this 2-part article. http://codepyre.com/2010/03/using-ninject-extensions-interception-part-1-the-basics/. I have tried both the method registration and attribute approaches, but neither approach will let me intercept methods on classes that aren't registered in the kernel.
The problem is that mine is a multi-tenant system where I often have to do different concrete operations depending on the client who is logged in. I execute the correct functionality using the Factory Pattern to give me the right class for each client as needed. However, the classes served up by the Factory are not in the kernel and therefore cannot be intercepted.
I'm looking for any sort of solution to this problem including an architectural rework if necessary, so that I can make everything Interceptable.
What you probably are looking for is aspect oriented programming (AOP) libraries.
Look at this question: What Aspect-Oriented Programming (AOP) libraries for .NET are still actively developed?
We've started considering using BreezeSharp as we have a WebAPI ODATA Service that we'd like to re-use with a ASP.NET site (no javascript involved, just pure C#).
Unfortunately, we just noticed that, according to the documentation, all of our model entities should now inherit from Breeze.Sharp.BaseEntity. That's a no go for us as this would mean having a dependency on Breeze in our business model. We'd rather keep this dependency on the WebAPI service only.
Is there anyway we could avoid this ? Having proxy classes on the client-side for instance when they don't inherit from BaseEntity ?
Any thoughts on this ?
The Breeze.Sharp.BaseEntity requirement is purely on the client side, and the reason for it is to provide all of the persistence, navigation, key-fixup, change tracking and notification and other services that make the breeze client so easy to use.
There is an IEntity interface that Breeze.Sharp.BaseEntity implements and you are free to implement it instead of using the Breeze.Sharp.BaseEntity, however, this is a very nontrivial task. We are considering offering some guidance on this at a later date if our community generally finds it desirable.
We are also planning on releasing an AOP implementation of IEntity that can be injected directly on top of POCO model objects, but this is likely to require PostSharp and may also have issues running on some client platforms (Xamarin for Android/IOS). No timeframe for this until we get a sense of the demand.
The current implementation on the other hand is very respectful of your model objects, there is only a single 'EntityAspect' property added to your model along with several events.
We have tried the pure POCO approach in the past, on numerous other platforms and application libs and have found that the disadvantages outweigh the minimal cost of a base class, especially when considering that we wanted this library to run in any .NET client including Xamarin/Mono.
If I understand correctly, your only concern is that you don't want to refer to breeze# libraries in your server model. Apparently you have no issue with close coupling of your client and server entity classes in the sense that they have identical properties and perhaps shared methods as well. I'm not being judgmental; I'm merely trying to confirm your architectural decisions.
Have you considered partial classes?
You define the partial class w/o breeze in your server-side business model project and link to that class source in your client model project ... where you keep the companion partial class with the client-specific functionality. That client partial class file specifies the breeze# base class.
While you are at it, you can segregate server-only logic in partial class files that reside in your server project but not in your client project.
Such source file linking has become even easier with VS now that Microsoft is promoting it in their vision of "Universal apps".
I am currently viewing multiple tutorials (and reading books) to start working with ASP.NET MVC.
I see that ninject (or similar) is widely used to implement Dependency injection and from what i understood the main issue here is resource allocation from the classes i need.
We want to be sure for example that we have only one instance of the repo object.
I need to learn first things first so i am interested in knowing how i would create an ASP.NET MVC without using DI techniques and still be correct as far as my object resources are concerned
More info:
I have made some winforms applications. These apps where using a Business Layer DLL (BLL). This BLL had access to my DAL DLL (plain ADO.NET). they are working quite well..
No i want to use the SAME BLL to MVC apps.
With injection or not?
Without injection implementation?
Do i just create the BLL object in my controller constructor and that's all?
ASP.NET MVC doesn't require you to use dependency injection at all. It will work perfectly fine if all of your controllers have default constructors. On the other hand, you will be responsible for creating the objects and managing their lifetimes. If you need to have one repository object for the application, you have to manually implement its lifecycle(using a static variable or Singleton pattern).
If you care about testing, using dependency injection will certainly help you to design more testable and reusable objects. You can easily replace the dependencies with test doubles in your test code and let DI container inject the real implementations in the runtime.
If you are sure about not using it, then make sure all of your controllers have default constructors. You don't need any configuration.
Dependency Injection is not a requirement for using ASP.net MVC. You can definitely build an MVC app without it.
Where it will come in handy is if you want to perform unit testing on your application. If you would like to unit test an action in a controller, if you have DI set up, then you can mock your dependencies that are included in the controller constructor (that DI takes care of when the app is running) and set up responses to return when they are called by the Action.
This is much harder and impractical (if not impossible) to do if you are not using Dependency Injection. In such a case, if you want to use Unit Testing, it will be very hard to write pure unit tests of your Actions, since you will have no easy way to mock your service and data access layers for your tests.
And as you wrote, the DI layer will also enable you to ensure things like having only one instance of the repository objects that you are injecting, etc.
We are currently using Autofac as our chosen IoC container. All application code in our reusable assemblies must be kept as clean as possible, so we do not want any direct dependencies on Autofac in our core application. The only place where Autofac is permitted is in the composition root / bootstrappers, where components are registered and wired up. Applications rely on dependency injection to create the required object graphs.
As we are keeping our core application container agnostic, it means that we cannot use the Autofac relationship types, such as Owned, in our core application.
I would like to create a factory that returns components that implement IDisposable. As Autofac tracks disposable objects, I believe I have to use a lifetime scope to create a defined unit of work in which components will be disposed once they go out of scope.
According to the Autofac documentation, this can be achieved by taking a dependency on Func<Owned<T>>, however, as stated above, I cannot take a dependency on Owned as it is an Autofac type. At the bottom of this page, it says
The custom relationship types in Autofac don’t force you to bind your application more tightly to Autofac. They give you a programming model for container configuration that is consistent with the way you write other components (vs. having to know a lot of specific container extension points and APIs that also potentially centralise your configuration.)
For example, you can still create a custom ITaskFactory in your core model, but provide an AutofacTaskFactory implementation based on Func<Owned<T>> if that is desirable.
It is this implementation of ITaskFactory that I believe I need to implement, but I cannot find any examples.
I would be very grateful if someone could provide such an example.
Probably the best "real-world" example of this is the Autofac MVC integration mechanism. While it doesn't use Func<Owned<T>> under the covers it does show you how you might be able to implement a non-Autofac-specific mechanism to talk to Autofac under the covers.
In the MVC case, the System.Web.Mvc.IDependencyResolver is the interface and the Autofac.Integration.Mvc.AutofacDependencyResolver is the implementation. When ASP.NET MVC requests a service, it gets it from System.Web.Mvc.DependencyResolver.Current, which returns an IDependencyResolver. At app startup, that singleton gets set to the Autofac implementation.
The same principle could hold for your custom factory. While IDependencyResolver is not specific to the type it returns (it's just GetService<T>()) you could write a type-specific factory interface just as easily.
Im new to IOC and StructureMap and have an n-level application and am looking at how to setup the wirings (ForRequestedType ...) and just want to check with people with more experience that this is the best way of doing it!
I dont want my UI application object to reference my persistence layer directly so am not able to wire everything up in this UI project.
I now have it working by defining a Registry class in each project which wires up the types in the project as needed. The layer above registers its types and also calls the assembly below and looks for registries so that all types are registered throught the hierrachy.
E.g. I have UI, Service, Domain, and Persistence libraries. In my service layer the registry looks like
Scan(x =>
{
x.Assembly("MyPersistenceProject");
x.LookForRegistries();
});
ForRequestedType<IService>().TheDefault.Is.OfConcreteType<MyService>();
Is this a recommended way of doing this in a setup such as this? Are there better ways and what are the advantages / disadvantages of these approaches in this case?
This sounds good.
If you use default conventions, like having a default implementation OrderSevice for the interface IOrderService you can reduce the wiring by using conventions in StructureMap. The WithDefaultConventions is a method in the Registry to use default conventions. You can also specify your own convention and register it in the registry using the method With, see the StructureMap documentation