Generating nHibernate cfg file from Configuration instance - nhibernate

Is there any way for me to generate an nHibernate configuration file from a Configuration instance (that has been already configured by some external code?). I'm looking for an easy way to mimic this external code with a static XML file?
(I guess similar to the "ExportTo" method that Fluent nHibernate has for fluent mappings - but acting on the resulting Configuration object instead).
Thank you!

No, there is no way to do that easily.
What can be done (and is common) is binary serialization of the configuration. Check http://github.com/ayende/Effectus/blob/master/Effectus/Infrastructure/BootStrapper.cs

Related

How to set custom name, suffix for mapper files and interfaces in mybatis generator?

Can you set custom suffix and naming rule mapper xml and interfaces in MyBatis Generator (MBG)?
For example, When generating mapper files for class Book. MBG generates mapper file BookMapper.xml and interface PartnerDao.java. However, I wish to change the suffix to something else, like BookMapperBase.xml or BookDaoBase.xml, and PartnerMapperBase.java or PartnerDaoBase.java.
The reason is, former colleagues were using BookMapper.xml for their hand-written sql statements and using the same name would cause confusion. Moreover, I do not wish to use generated mappers directly, but use custom mapper files that extend BookMapperBase.xml.
I have searched online and found some github projects and hot rod ORM, but is it really not supported by official Mybatis Generator? If not, what is your recommended alternative?
There are a couple of options.
You could use a domain object renaming rule as documented here: http://www.mybatis.org/generator/configreference/domainObjectRenamingRule.html
If that doesn't work the way you want it to, you could write a MyBatis Generator plugin to change the names of the generated artifacts. There is an example here: https://github.com/mybatis/generator/blob/master/core/mybatis-generator-core/src/main/java/org/mybatis/generator/plugins/RenameExampleClassPlugin.java

Taking control of WSDL/XSD from WCF-SVCUtil (Annotations, Schema Namespaces, and Schema Locations)

In the WSDL that is generated from a WCF service, there are a few problems that I'd like to take control of a little more. First, is there a way to add annotations to the xsd files generated with the WSDL without using surrogates?
I've taken care of adding annotations to the WSDL itself thanks to the following articles:
http://msdn.microsoft.com/en-us/library/system.servicemodel.description.iwsdlexportextension.aspx"
http://www.codeproject.com/Articles/29980/Exporting-Annotations-from-WCF
I was able to add annotations to data members through agillior, however they used surrogates which I would rather not use.
http://agilior.pt/blogs/bruno.camara/archive/2006/10/01/6.aspx
I would use Thoranin's solution except I want to apply the annotations to data members not parameters
http://thorarin.net/blog/post/2010/08/08/Controlling-WSDL-minOccurs-with-WCF.aspx
Second, I want to explicitly name the namespaces for the xsd files generated from the WSDL. I was able to take control over the namespace of the wsdl using the ServiceBehaviorAttribute: [ServiceBehavior(Namespace="http://mysite.com/HelloWorld")]
but unfortunately I can't find an easy way to specify the namespace of the xsd files :(, is there a simple way to do this/can you point me in the right direction?
-edit-Well I was being silly on the second request. I had forgotten to set the namespaces for my wcf files which is what maps to the xsd namespaces. My bad :) .
Lastly, when the wsdl imports an xsd, it uses a path similar to http://localhost:8080/HostDevServer/HelloWorldService.svc?xsd=xsd0
which seems to break the wsdl2java ant script by apache. I can go in and manually change them to the local files but it's just such a pain :). Is there any way to have the files generated and then have a local reference like:
HelloWorldService.xsd,HelloWorldService1.xsd etc?
Any feedback would be appreciated.
WCFExtras ftw:
I decided that instead of having my own attributes and classes put documentation/annotation into the WSDL and XSD files I would just give into the hype and let WCFExtras take care of it. That being said I do wish that the Xml comments would be split into different lines instead of having them all on the same line. (Just to make reading the xml files easier). Plus WCFExtras takes care of the surrogate problem perfectly :) !
Ended up writing a program to solve the third issue. It pretty much grabs the metadata files using svcutil then goes in and finds all the imports, and reassigns them to the files downloaded based of off the namespaces.

Fluently map assemblies/entities at run time

Simple question for I bet a not so simple answer.
Think of a project like Wordpress. The base of Wordpress is great and the developers built it to be extended with widgets or plugins etc.
Now think NHibernate, specifically with Fluent Mappings.
Put them together and you have a great and stable "base" system BUT how do you load mappings presented from external assemblies? I realize that the system would have to load the Assemblies on the fly using reflection but how do you configure nHibernate, Fluently, at first run to realize that there are extra entities to be loaded from those assemblies? How do you reference them?
I know you can;t add Mappings at run-time after the configurations is made, well you have to recreate the SessionFactory. This is why I want to load all required entities at runtime.
I also know that this can be somewhat accomplished with Dependancy Injection but I do not wish to go that route nor want the extreme baggage that comes with it.
If the plain old nHiberante config file can be modified and then referenced at runtime to reflect new Entities I can only assume there has to be a way to do it Fluently.
Also, based on answers: do you make the configuration from the base project or a DATA ACCESS assembly?
Thanks for your help.
You can pass an NHibernate Configuration object to Fluently.Configure(). That way you can update the configuration. You need to re-create the session factory when you do that, like you said.
You can scan the assemblies in the bin folder for assemblies that contain fluent mapping classes (Assembly.Load, then check
Assembly.GetExportedTypes()
.Any(x => x.IsClass
&& !x.IsAbstract
&& typeof(IMappingProvider).IsAssignabledFrom(type))
or similar) and add the assembly. When all assemblies are scanned, (re-)create the session factory.
I'm doing something similar in an extensible application framework I have written (although I've moved to from Fluent NHibernate to NHibernate mapping by code, but the principles are similar).

What is the preferred way to configure a mono application

When using VS, the preferred way to store user- and application settings seems to be to access VS "settings" tab for the given assembly and simply type the settings you need.
Monodevelop does not have this feature (or at least I did not find it...)
What is the preferred way to do this under mono using monodevelop?
If the answer is "well, do the same - but hand-type the code needed" I'd love some pointers to a nice tutorial.
On the mono list, John Ludlow had the answer I needed:
...First, the ConfigurationManager (
http://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager.aspx ) will expose two section handlers by default...
If you want more complex configuration option then you can define your own
handlers by inheriting from ConfigurationSection and ConfigurationElement.
See http://msdn.microsoft.com/en-us/library/system.configuration.configurationsection.aspx
and http://msdn.microsoft.com/en-us/library/system.configuration.configurationelement.aspx.
You may also need to provide a class inheriting from ConfigurationElementCollection
as well, if you want to be able to configure a collection of values.
Thanks to John and the people of the mono-list.
You still can use .settings files to keep settings, just edit them by-hand.
Also you can use App.config / another .config files

Should DLLs have their own configuration files?

Apologies if this is a duplicate, but I've not managed to find this question being asked directly.
The general opinion here (that's me and him across from me) is that they shouldn't, the reason being that DLLs can be shared; therefore the idea of having application-specific information in a DLL is nonsense. If the information is not application-specific, then constants can be used.
A further question is, assuming that DLLs do not have their own config file, whether DLLs should use the configuration files of the executable that loaded the DLL, or instead be passed the relevant data as part of some kind of constructor. Our opinion here is the latter, as it makes it more testable, the downside being that it will sometimes be necessary to pass a significant amount of data to the dll.
Opinions?
There's no reason why you can't have the best of both worlds in terms of "simple to configure with config files" and "testable". Have a static method which can create instances from the configuration file, but also provide a constructor for more control and testability. The static method would just grab the settings and call the constructor.
I believe it's possible to create settings classes for DLLs just like any other project, and then you just need to put the actual text into the application's config file instead of one for the DLL. Basically ignore the app.config generated for the library project, except to use as a template for the application's central one.
Alternatively, use something like Spring.NET to manage this sort of thing :)
Usually, I guess you should pass relevant information to the functions you're calling or set relevant properties in objects you're creating that are defined within the DLL. I guess that's why .NET does not really support config files for DLLs (you can create them, but they'll not be used when running).
I have one scenario, where DLLs are reading a config file, but that is very special: The .NET DLL exports objects as COM objects for use by Microsoft Navision. It communicates with a factoring bank using an XML-RPC interface.
While the DLL is installed on every user's machine, the configuration for the interface is common to all users, so I have a configuration placed on a network drive that's mapped on every PC and the configuration (URL, credentials, etc.) is read from that common file.
Whether that's good practice is up to the reader, but in that scenario having a common config file just made sense...