1) Is it possible to use Burrow with winforms application or WPF application?
2) Are there any samples how to configure Burrow with winforms app.
Even if it is possible - you should not. Burrow uses HttpModule to configure ISession, ISessionFactory lifetime.
You won't get anything usefull from burrow except implementation of DAO objects and some base classes for entities. I think you better move the source code of required parts in your application and use them.
What about using
new NHibernate.Burrow.BurrowFramework.InitWorkSpace();
new NHibernate.Burrow.BurrowFramework.CloseWorkSpace();
These methods create and destroy the Session without using httpModule. So it can be used in unittests where u cannot supply the module. => what about winforms apps? The question is still opened
Related
I need to write an application which can load plugins. I read the PRISM 4 documentation and i like the "Region" concept of the framework. But all modules are loaded in the first AppDomain - but i need to build an application where 3rd party plugins can crash without crashing the whole app (so i think multiple app domains are the best solution?)
Has anybody some experience with that topic? Should i build it on top of MVVM light myself? Is PRISM 4 the tool I'm looking for?
Thanks and best regards
To the best of my knowledge, none of the popular MVVM frameworks (Prism, Caliburn, Calcium etc.) support cross-appdomain module lifecycle and, just as importantly, cross-appdomain messaging out of the box. This said, it's not impossible to customise any of them to:
allow for modules to be loaded in different appdomains, perhaps based
on some configuration option;
create a remoting proxy for their messaging components (eg. event aggregator in Prism) so that a message is serialised into a different appdomain.
For one, Prism4 allows for multiple extensibility points on its bootstrapper, module catalog and service locator components, so loading DLLs and initalising their entry points on different appdomain is not too hard. Creating a remoting proxy of the event aggregator is a bit more complex.
I have personally resorted to creating a different message broker that works cross-process as well as within the same appdomain, however I had to write it from scratch.
I'm confused about the architectures which we can use to develop a business application with WPF 4.0 and EF 4.0 technologies.
My first choice was a traditional N-tier architecture contains: UI, Business Logic Layer & Data Access Layer with a disconnected behavior.
In this way I create 3 project for each layer and another project for my Entities/DTOs (Each layer is an assembly). Each layer references only to it's upper and lower layers (That is: UI can see the BLL but can't see the DAL). But all layers have access to the Entity/DTOs assembly for communication purposes.
The problem starts when I want to create a simple CRUD form with a DataGrid for example. The BLL disposes the DataContext of the DAL when returns an Entity/DTO, this is the reason that forced me to use STEs. But yet there are several problems. For example I should call "StartTracking" method for each entity returned from BLL to the UI. In short, I don't sure about this pattern reliability or I think I have to forget about automatic handled CRUD forms.
I use the repository model in my DAL layer but when I search about the repository pattern I find it different. It seems that it's not bad to reference to both of the DAL/Repository and the BLL/Services(Not WCF nor WebServices) layers from the UI and thus we can have a connected environment (Without using STEs).
I see an example in which we can get a person from repository but do something on it using BLL or services:
UI CODE:
var person = new PersonRepository().GetPerson(10);
Bll.Salary.PaySalary(person);
-or-
var person = new PersonRepository().GetPerson(10);
Bll.Person.MarkAsAbsent(person);
Or something like that...
With this pattern we can send the Entities/DTOs to the UI in a connected way while the DataContext is alive.
I don't know if I understand the way of using the repository pattern in big projects. I think it's not clear to naming the BLL or services classes and methods in this way. More over the developers might be confused about where to use the repository methods or BLL/service methods or about where to create the methods (in repositories or BLL/service).
I prefer the N-Tier architecture using a good approach to track the Entities/DTOs changes automatically like STEs.
Would you please recommend the best pattern in such situations or/and reference me to some good books or documents about that.
I put together a sample app that may help with some of your questions. You can review the presentation notes and the sample via my blog post here:
http://blog.alner.net/archive/0001/01/01/wpf_ef_4_sig_presentation_2010.aspx
The sample shows using STEs and includes some helpers to make the Entity Framework STEs work better in a desktop client app.
Repositories are there to hide the details of how you get the data. The idea is that you could swap the implementation of a repository from one that uses a local database, to one that uses a remote web service without the upper layers knowing about it.
Maybe the article Architecture for WPF applications is any help for you.
You might have a look at the BookLibrary sample application of the WPF Application Framework (WAF) as well. It shows a WPF MVVM application together with the Entity Framework applying the described architecture.
I downloaded Prism v4 and ran the installer. I went into the directory and ran the two following batch files:
Desktop only - Open Modularity With Mef QuickStart.bat
Desktop only - Open Modularity With Unity QuickStart.bat
When I compile these applications, I don't see any real difference. I've searched for MEF vs Unity and I've found some pros/cons, but nothing that specifically states whether one is "better" (and I know that is subjective) with use in Prism. I guess perhaps if I list my requirements someone can point me to the correct technologies to use (even if it's not Prism 4).
The application is to be written in WPF (NOT Silverlight).
The main application will be extremely thin.
The main application will use a Web Service to build the menu of the "apps/modules" a person has access to.
The "apps/modules" will be completely contained in other managed libraries.
The main application gets views and viewmodels by reflecting into these DLLs.
The main application should feed in services for logging, etc. into these "apps/modules".
For example:
A basic user might have the options of:
ViewOnly Address record
All items Address related are within Address.dll.
An advanced user might have the options of:
New Address record
Open Address record (update/delete)
Manage users
All items Address related are within Address.dll.
All items Manage related are within Admin.dll.
The app should not actually reference either of these DLLs, I plan to reflect into them so that if there are 100 different modules and a user only has access to 2 of them, only 2 of them are downloaded and used. Whereas a user that has access to 10 of them gets those 10.
I've already solved the downloading DLL via WebService. :)
None is "better": they are different things.
IMO your choice should be driven only by your requirements. Based on the requirements you posted here I would suggest you to use MEF, because you have modules contained in DLLs and the main app is unaware of modules to load. Those tasks are the reason that why MEF exists.
Anyway you could use them both: MEF for modularity and Unity to take advantages of dependency injection (testability, reusability, ...)
If all the modules are not recompiled at the same time as the app, then MEF gives you lots of ways to cope with changing interfaces in the main app. Otherwise MEF may be more complex then you need.
I've been using Unity over a year with PRISM but I've noticed some serious memory leaking issues. Hence I decided to give PRISM 4 and MEF a go. What I've done is firstly converting my app to use PRISM 4 with Unity. Then I converted a branch to use MEF.
It may sound funny but MEF seems to handle memory consumption and release somehow better than Unity.
Would be nice to hear whether others have made the same experience?
Regard to your question whether MEF and UNITY can work nicely with each other, i can tell you that they are working really well with each other. I have developed a proof of concept application which used PRISM, Unity and MEF.
I have read most of the literature Google and SO provides on this (correct me if I've missed something).
What I am trying to do is to localize an MVC site using resources, I want the compiletime safety of strongly typed resource files (ResX) but the flexibility of the ASP.NET 2.0 Resource-Provider Model, or something similar to that. I dont mind doing some work but it seems all paths I've researched lead to a dead end.
For displaying localized text in views I can hack together a helper to pull resources from HttpContext.Get(Global|Local)ResourceObject but that gets me nowhere when it comes to model validation and scaffolding, I suppose I could subclass the attributes and provide data but since it means pulling stuff from HttpContext I doubt that is available at the time the attributes are activated.
Since the direction localization in MVC seems to be toward ResX files and away from the 2.0 Resource-Provider model I could try to inject myself in the classes generated by the ResXFileCodeGenerator with a custom ResXFileCodeGenerator to provide my own ResourceProvider but that is terribly hackish involving custom Visual Studio Addins and codegeneration.
So my question is basically, what's the story with flexible MVC localization?
The referenced literature below:
http://adamyan.blogspot.com/2010/02/aspnet-mvc-2-localization-complete.html
http://msdn.microsoft.com/en-us/library/aa905797.aspx
http://www.eworldui.net/blog/post/2008/10/ASPNET-MVC-Simplified-Localization-via-ViewEngines.aspx
http://ryanrivest.com/blog/archive/2010/01/15/reusable-validation-error-message-resource-strings-for-dataannotations.aspx
http://www.codeproject.com/KB/dotnet/ResXFileCodeGeneratorEx.aspx
A resource provider should work fine (i.e. http://msdn.microsoft.com/en-us/library/aa905797.aspx). I've been using this in some projects with a SQL Server backed provider, works fine. It allows you to use all ASP.NET localization features and all the validation attribute translations using resources as well.
Please try a dedicated NuGet package for localization of MVC applications with database resources:
Globsite.Globalization.Mvc
It is built on the native ASP.NET Resource-Provider Model, so it can be integrated with your application in the similar way like standard ResX resources.
What is more, the library allow you to generate Strongly Typed Resources just with a single click, if you need.
The project site with more details:
globsite.net/GlobsiteGlobalizationLibrary
What's the fastest communication model for a Silverlight component communicating with a WPF component? That is, at the very least I'd like to consume an event from a Silverlight component in a WPF component.
I understand you can use WCF to build a bridge
I understand you can use Javascript to bridge from WPF -> Silverlight (and I have that working)
I understand you can use COM to go the other way (Silveright -> WPF)
However I'm looking for a tighter communication model (not using COM) - perhaps like EventAggregator (Silverlight component pubs, WPF component subs)...but I've only seen eventAggregation in WPF or Silverlight but not both at the same time.
Any ideas for creating such an eventAgg / eventBus, without using WCF, without using COM?
Open to any approaches / ideas; might be something I haven't considered.
Thanks.
Interesting challenge - could you provide a little more detail on why you need to do this?
My first question is: Are you envisioning these two apps running on the same machine, at the same time? Both are important.
If the answer is yes (same machine, both running) then you should be able to implement a solution using WCF, with the service self-hosted in the WPF app, the Silverlight client referencing it, and a cross-domain policy setup appropriately.
If the answer is yes, but not at the same time, then you'll need a third party, like a Message Bus, perhaps implemented as a Windows Service. NServiceBus comes to mind.
In any case, WCF really is the best solution for messaging in Silverlight. If you were going Silverlight app-to Silverlight app there is a mechanism for that that doesn't require WCF.
A message bus would give you the Event Aggregator functionality you're thinking of - a player who is always there to accept subscriptions and publications.
Another option (if running at the same time) is to elevate your Silverlight app to full-trust and use Sockets. See this link for more info (he provides an example that may be helpful).