As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Trying to decide between Dapper, Massive and PetaPoco. I do like simplicity of Dapper, flexibility of Massive and POCO support in PetaPoco but am currently procrastinating about which one to choose for my next project.
I do realise that, to a large extent, it's the matter of personal taste, but believe it will be valuable to hear some opinions on the subject, especially from people who tried more than one of these, err, libraries (what is the right term: library, file, framework?)
Try to decide which of the features you mention -- simplicity, flexibility, POCO support -- will be most useful to you and your project(s) one year from now. Which is most likely to make your work easier?
Then you'll have your answer. And if you still can't choose, pick Dapper (just a random selection I made :-) As the Cheshire Cat says, if you don't really know where you want to go, it doesn't matter which road you choose.
PetaPoco's documentation seems more mature than others. It seems like it is the safest route.
i havent triend any of those. by default i always base my decision on number of lines of resulting client code and type safety. of course there are number of other metrics you should take into account but if your project is not constrained by any special (exotic) requirements those two are generally appliable.
btw. i am aware about controversy my response may lead to ;)
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
A few months back, we introduce Rx into our codebase, and since then the codebase is getting more and more "reactive". I feel that it is really easy to introduce concurrency into the codebase with Rx, as not a single line of "locking" was used yet.
However, I do not understand why it is easy with Rx when I can't explain it in words.
Is it related to the "Actor Model" and "Functional Reactive Programming" concept?
Can someone kindly enlighten me on this please?
I think the main reason it's "easy" is because of the blood, sweat and tears poured into the Rx library by the very smart Dev team behind it at MS.
Look at the (open) source code to see just how much careful code goes into enforcing the Rx grammar and the parameterisation of when and where things run using Schedulers. That has plenty of defensive concurrent code in it. I suggest it's the grammar and Schedulers that bring the simplicity.
Using the model is quite easy, but achieving that simplicity was not trivial. You are benefiting from standing on the shoulders of giants that have hidden the complexity behind a neat and tidy API :)
Incidentally, there is still the odd trap for you to fall into... I'm sure you'll find one sooner or later! One example is that Subject<T>.OnNext() is not protected from concurrent access in Rx 2.x for performance reasons.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a lot of legacy code where json is parsed manually by using a for loop. This takes O(n) time in general. I know json.net would be better in terms of time and space but gaining an insight about how it works, would help me make an informed decision whether its worth the effort to actually go ahead and invest the time and man power to move everything to json.net.
To paraphrase your question into a more general one, lets assume you were looking for advice on which JSON serialization implementation to choose for various scenarios.
I'm aware of three obvious answers to this question:
NewtonSoft JSON.NET
Provides an abundance of features and excellent performance
ServiceStack.Text
Provides simplicity and blazing performance
BCL JsonSerializer
Avoids the 3rd party library dependency, but is significantly slower
If you don't care about the 3rd party library dependency, go for the first option as it will give you performance and functionality. If you don't need a ton of features, evaluate whether ServiceStack.Text does what you need it to (if unsure, go with JSON.NET). In any other case, stick with what you have.
Also, don't spend time making your code faster by replacing your JSON code before you know that this particular area is a performance bottleneck (or otherwise warrants replacement, e.g. because it's a maintenance problem). If you are considering replacing code to gain performance, isolate a few methods to profile and benchmark your current code against similar scenarios using the alternate implementation or library, in order to avoid making a decision based on assumptions.
Last, knowing how it works internally should not be a factor in your decision process unless you specifically are planning to be able to modify the source of it (or otherwise need to be able to understand it).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Button: btnDoSomething
Button: DoSomethingButton
Property: FirstName
field: _list
The first I used to much. I want to see or learn new ways for my future codes. Use the best practices or general rules for naming them.
All your variables, fields, properties, classes.
Too many.
Worrying about that can be a drag on your productivity. Luckily enough, other people have already done the worrying for you, so you can follow these guidelines and concentrate on other issues.
http://msdn.microsoft.com/en-us/library/ms229002.aspx
.Net (and, I believe, MSVS) ship with a tool called "FxCop". Which, among other things, warns you if you violate "CamelCase" conventions:
http://www.binarycoder.net/fxcop/html/tutorial.html
Two links that might help:
MS Style Guidelines
A Brief History of Dueling Style Guidelines
Enjoy :)
PS:
Personally, I think Kernighan and Ritchie got it right in the first place ;-)
The first way of naming the button btnDoSomething is called Hungarian Notation and its obslete now. The second way is also having the Button as a suffix which is also equally unnecessary.
Why not just use ID="DoSomething"?
Here is a good read: http://10rem.net/articles/net-naming-conventions-and-programming-standards---best-practices
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
We are about to implement a small automated securities trader. The trader will be build on top of the excellent quickfix FIX engine.
After due though, we narrowed our options down to implementing it in C# or in Python. Please specify the pros and cons of each language for this task, in term of:
Performance (The fact that Python uses a GIL troubles me in terms of thread concurrency)
Productivity
Scalability (We may need to scale this trader to a fully-sized platform)
EDIT
I've rephrased the question to make it less "C# vs. Python" (which I find irrelevant - both languages have their merits), but I'm simply trying to draw a comparison table before I make the decision.
I like both languages and a think both would be a good choice. The GIL might really be the most important difference. But I'm not sure if it's a problem in your case. The GIL only affects code running in pure Python. I assume that your tool depends more on I/O than on raw number crunching. If your I/O libraries handle the GIL correctly, they can execute concurrent code without problems. And even for number crunching you still have numpy.
My choice would depend on your existing knowledge. If you have experienced C# developers at hand I would go for C#. If you start absolutly from scratch and it's really 50:50, then I would go for Python. It's easier to learn, free and in many cases more productive.
And just to mention it: You might also have a look at IronPython. ;-)
For points "Performance" and "Scalability" I would suggest C# (although a large part of performance depends on your algorithms). Productivity is much of a subjective thing, but now C# has all cool features like lambda, anonymous method, classes etc which makes it much more productive.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What are some of the open source projects out there that you would hold up as shining examples of projects that correctly and effectively use enterprise sofware patterns and best practices such as Inversion of Control, Model-View-Controller, Unit Testing, etc.?
For purposes of this question the project should:
Include source code that illustrates the pattern in use, and
Be doing something important and useful, i.e. not using the pattern frivolously just because it is flavor of the week. Hence the words, "Correctly and Effectively" in the question
It should be software that you could show to the people who work for you and enthusiastically be able to say, "I want you to do it the way these guys did it."
Most of the GNU project is very very well written, over a very long period of time, with strict guidelines.
Prism is very good for MVVM in WPF and Silverlight
patterns they use Patterns in the Composite Application Library
An objective pick would be the Spring Batch project.
How did I pick it? Judging from the technical debt as seen on the Nemo Sonar instance, Spring Batch has the lowest debt/line ratio for projects larger than 10k lines of code.
When I first looked at the source code for DotNetBlogEngine, I was impressed at how well it was organized. And it didnt couple any of its components to the interface, making it extremely flexible.
It's not a terribly huge project either, not like trying to recompile your own linux kernal or something. So you can dive in quickly and have some fun with it.
Castle project
You can try this book - Beautiful Code
The author has collected some experience-sharing articles of open source projects. e.g. Python's Dictionary Implementation, Subversion's Delta Editor, etc.
You mean Spring? Or projects that use it?
UPDATE: WebWork, Guice, and Spring Security all fit the mold.