1 Answer
1

Depends. You are essentially asking to construct things imperatively (code) or declaratively (XML).

If you only need a few instances of your list, all of what you said could be done using SharePoint Designer. If you need to reuse the content types and lists in many sites/site collections, I'd do it with features (aka CAML...aka XML). You could construct the artifacts you mention in the SharePoint Browser User Interface and/or SharePoint Designer. Then do a "save site as template". Then export the .wsp from the Solution Gallery. Using Visual Studio 2010 (or 2012), import the .wsp and pull out the content types and list definitions. You'll need to tweak things a bit, especially the lists to make them "true" List Templates. Then package and deploy the resulting wsp and features.

The tooling was not always there to support the declarative approach, but with Visual Studio 2010 and 2012 (+ the CKS Dev Tools), the tooling is improved to the point where it's more manageable. That said, it can still be a tedious and time consuming task. However, from what you have outlined as your requirements (needing to deploy to multiple clients, sites/site collections, etc), the declarative approach seems the right way. Again, designing in the UI/SP Designer and exporting/importing the .wsp will get you about 50-60% there.

For the Events (assuming you mean event receivers), you will need code. To register the event receivers with the list, you can use either code or declarative approach.

For multilingual, depends on your needs, but you could probably leverage the Multi Lingual User Interface functionality (AKA MUI). If you need things provisioned using RESX files, declarative seems a simpler approach. However, be careful about using RESX files in Sandbox solutions.

Thanks for you answer Brian. To be more clear. We forget Designer. This project will be used in many sites, in many customers. So the question is: using VS2012 create the List with XML or with code (SPList class and so on)?
–
pbarisFeb 7 '13 at 7:45

Updated answer a bit to flush out thinking a bit more on the decision. Personally, I'd be using a declarative approach for as much as I could (everything except the actual code of what the event receivers do). Even with the Event Receivers, I'd look at possibly using workflow depending on what they need to do.
–
BrianFeb 7 '13 at 14:20