If you we're about to start a new project with some third party libraries (logging, orm, di, whatever), would you prefer to configure all this libraries via programming with fluent interfaces or with XML files?
Would you use a library that only supports one of these options (Fluent or XML)? Or do you prefer libraries that gives you the possibility to choose between a variety of configuration strategies.
For those who like code, take this as a hypothetical example (written in C#).
This is Fluent Configuration:
LogConfiguration.ConfigureStorage()
.ForDatabase("CommonDB")
.AsMsSqlDatabase()
.WithConnectionString("server=(local); database=Northwind; Integrated Security=true;")
.AsDefault();
This is XML Configuration:
<logging>
<database name="CommonDB" provider="MSSQL" connString="server=(local); database=Northwind; Integrated Security=true;" default="true" />
</logging>
Finally, what are the Pros and Cons of Fluent and XML Configuration?
Until now, we've come to this:
Fluent Configuration in Code
Pros
Strongly typed evaluated by compiler
Conditional configuration
Cons
Unabled reconfigured after build
XML Configuration
Pros
Ability to easily change after deploy
Cons
XML is verbose
More vulnerable to typing mistake
I tend to use xml for attributes I might want to change post-build (such as connection strings, loggers)
I prefer strongly typed (compiled) fluent configuration in code for things such as NHibernate mappings that only change during development.
If I understood you correctly by fluent you mean in code? If so, then definitely I'd choose XML. If by fluent you meant pure text files, then still I'd choose XML.
Pros:
readability
self documenting tags (of course if you create those ;) )
Cons:
file length, but I wouldn't bother that
Currently all my projects are XML based.
I would say that XML configs may be less verbose and even simpler than Java configs.
Look on my comparison of the same config on XML and on Java DSL in Spring Integrations's wireTap config
Also XML configs may be more familiar to less experienced programmers. So efforts for maintain such configs in the future may be less.
Related
Is it possible to pre-generate lazy-loading proxies under NHibernate 3?
NHibernate 2 supported this via NHPG but NHPG hasn't been updated for NH3 that I can see. Downloading the NHPG sources and blindly changing the assembly reference from NH2 to NH3 blows up; NH3 has built-in proxy generation and stuff has been reorganized.
How are people (pre) generating lazy proxies under NH3?
I've updated NHPG to support NHibernate 3.3.1 GA.
You could grab the sources here: https://github.com/NHibernate-Contrib/NHibernate.ProxyGenerators
You have to build it by hands (download the sources and run package.cmd) for now until we release an official version.
I don't know if this answers your question since I do not see any tag related to language that you are using.
In .NET, I use Fluent NHibernate and POCO objects. Don't know if there is a tool to upgrade your XML files to POCO classes to use with Fluent NHibernate.
What are the major differences between Rails 3 built-in logger and Log4r? It seems to me that Rails 3 logger gives you everything that you need.
Built-in logger is good enough for both development or production environment. especially at the very beginning stages of your project, you don't need to waste time to testing and choose an appropriate tool or library to do the logger job. You can concentrate on the project itself. the simliar situation like "erb" or "haml", "sass" or "less", "coffeescript" or "plain javascript", etc...
Log4r allow you to format your logs easily through configuration file. its a good built-in logger alternator when you real need it.
http://log4r.rubyforge.org/
What Log4r Is
Log4r is a comprehensive and flexible logging library written in Ruby
for use in Ruby programs. It features a hierarchical logging system of
any number of levels, custom level names, logger inheritance, multiple
output destinations, execution tracing, custom formatting, thread
safteyness, XML and YAML configuration, and more. Log4r is an adherent
to the philosophy of logging using simple print statements. What Log4r
adds to this philosophy is a flexible way of controling the
information being logged. Log information can be sent to any kind of
destination and with varying degrees of importance. Log4r is designed
so that logging statements can remain in production code with almost
no extra computational cost.
Log4r intends to be easy to use and configure, no matter the
complexity. Casual scripts can use Log4r right away with minimal
configuration, while more sophisticated applications can set up a
structured configuration file in XML or YAML. Comprehensive
documentation is provided, with a user's manual, a reference API, and
over a dozen examples. Log4r attempts to abide by the Principle of
Least Surprise, which means that it works as intended at all points.
Log4r was inspired by and provides much of the features of the Apache
Log4j project, but is not a direct implementation or clone. Aside from
superficial similarities, the projects are not related in any way and
the code base is completely distinct. Log4r was developed without even
looking at the Apache Log4j code.
Log4r is an Open Source project and intends to remain that way. The
Log4r license is similar to the Ruby Language license. It resides on
this page and in the distribution in a file named LICENSE.
We are working on SOA, both on client (Silverlight) and server (WCF) sides, but with possibility of the clients being implemented by 3rd parties (.NET, Java, etc.). We use WSDL-first approach and want our data and services interface classes (C#) to be automatically generated from schemas during build process. So we need common data classes code not being regenerated for every service for successful compilation.
I have tried the svcutil utility, trying to first create all data contract classes from XSDs with the /dataContractOnly switch, and compile them to separate class library - the first stage. And then to create each service interface code, omitting the classes already in the library, with the /reference switch - the second stage.
The problem is that our schemas do not meet the DataContractSerializer requirements, so svcutil cannot create data classes. Even after I used xsd utility for this purpose, I cannot use svcutil's /reference switch on the second stage, since this switch only works for DataContract classes. And this is not the case with the classes generated by xsd utility.
So, am I missing something with these tools and are there any way to use them in my situation, or are there any other tools to generate data classes and service interfaces from XSD and WSDL schemas, in case where common data types are used by several service interfaces? Or should we hardly limit ourselves with DataContract compatible schemas? What approach do you use for WSDL-first development?
Have you tried WCF.blue tool by codeplex?
WSCF.blue is a toolset that facilitates the development of web services using a contract first (specifically, a schema first) approach. This is the WCF version of the orginal Web Services Contract First tool.
Also, there is a beautiful article on Contract-First development:
http://msdn.microsoft.com/en-us/magazine/ee335699.aspx
Yes WSCF.Blue is a VS plugin as it ships but the source is available and so it can be rebuilt into a command line interface version like what we had to do, with little effort required I might add.
Any opensource tools for Generating NHibernate mapping file as well as class in C#?
If any other that are helpfull in using NHibernate, Please give me tools list.
Thanks.
MyGeneration is a pretty decent generator. And you can always use T4 which ships with Visual Studio 2005+.
I would recommend using T4. I use it myself to generate code from UML-models. I create the models in UML, and then use T4 to generate classes from the models. I wrote a short blog post about it, check it out if you want some more info on my setup.
If you have yet to try T4, there is no better place to start than Scott Hanselman's excellent post about that you can find here. Make sure you check the link list at the end of the post, it contains some of the best references for T4 information available.
You really also should look into Fluent nHibernate, and especially the "Auto Mapping" features that basically automatically generate the mappings from your classes. I use that to, and it is working great so far. You can very easily override the auto generated mappings wherever you have specific needs not covered by the auto generated stuff.
Hope this was helpful, good luck with your projects!
To follow up tmatuschek's answer:
I use FluentNHibernate to rapidly prototype my .hbm.xml files from my models using the Automapping feature like:
.Mappings(m =>
{
m.AutoMappings.ExportTo(#"c:\temp\mappings\");
m.AutoMappings.Add(AutoMap.AssemblyOf<MyWidget>());
}
After the files are generated from the automapping, I tweak the generated files, then reconfigure the app to use them instead of Auto/Fluent mappings. I find using the standard .hbm.xml mappings to be much easier once my model has stabilized a bit than using an automated mapper.
Currently I get to edit a lot of Spring.NET XML files, and I do find this work to quite repetitive and, frankly boring.
Most of the stuff I do is sort of 'refactoring' - generalising XML declaration for instances and "inheriting" from those generalised structures to declare more specific ones.
As I said, it's a no-brainier type of task but it does require a lot of attention and concentration and it's easy to make a mistake.
I would imagine that a lot of editing of Spring.NET xml files can be automated with a tool similar to ReSharper.
Can you recommend anything?
In the latest spring release (1.3-you can find files for ReSharper to help you with the XML files, though I haven't used them yet.
You might also want to look into Recoil which tries to avoid xml files and allows you to configure a Spring.NET powered application via code.
One of my clients uses Spring.NET quite extensively. I found the process of modifying the configuration files, starting the application and then getting a single, cryptic Spring.NET error at a time quite tedious. So I built a noddy validator that is now run as a post-build step on all executable projects. This will not help you with the actual refactoring itself but should let you identify any errors more quickly.
You can give it a bash by downloading it from BitBucket. I only developed the product until it catered for our use-cases so you may find that you will have to extend it to meet your needs.