I am new to C#, programming for less than a year. Until now I have been using the Micrsoft SQLHelper class. (copy of text header below) I recently came across Dapper.
Question is, should I switch to using Dapper ?
Although the SQLHelper class has worked with no issues, I don't know how old it is and I don't have enough experience to determine whether I should switch to using Dapper for xyz reasons. Is Dapper the preferred long term solution?
Thanks
// Microsoft Data Access Application Block for .NET // SQLHelper.cs //
// This file contains the implementations of the SqlHelper and
SqlHelperParameterCache // classes.
Is EntLib doing what you need and not inconveniencing you? Then: perhaps stay with it. Dapper would probably be more convenient in a lot of ways, and EntLib is arguably taking a complex API (ADO.NET) and making it more complex (as opposed to Dapper which aims to make things simpler for the caller), but: if the code works... shrug.
If you were starting from scratch, I'd 100% say "don't go near EntLib with a barge pole, Dapper is fine" (disclosure: I'm a little biased), but: if your code is working today, probably best not to touch it unless you have time to fix any problems you get while moving cogs.
Related
How can I store, for example, the body of a method in a database and later run it? (I'm using Delphi XE2; maybe RTTI would help.)
RTTI is not a full language interpreter. Delphi is a compiled language. You write it, compile it, and distribute only your binaries. Unless you're Embarcadero, you don't have rights to distribute DCC32 (the command line compiler).
However, the JVCL includes a delphi-like language subset wrapped up in a very easy to use Component, called "JvInterpreter". You could write some code (as pascal) and place it in a database. You could then "run that code" (interpreted, not compiled) that you pull from the database. Typically these should be procedures that call methods in your code. YOu have to write some "wrappers" that expose the compiled APIs that you wish to expose to the interpreter (provide access to live data, or database connection objects, or table/query objects). You're thinking that this sounds perfect right? Well, it's a trap.
Beware of something called "the configuration complexity clock". YOu've just reached 9 o'clock, and that's where a lot of pain and suffering begins. Just like when you have a problem, and you solve it with regular expressions, and "now you have two problems", adding scripting and DSLs to your app has a way of solving one problem and creating several others.
While I think the "DLL stored in a database blob field" idea is evil, and absurd, I think that wanton addition of scripting and domain-specific languages to applications is also asking for a lot of pain. Ask yourself first if some other simpler solution could work. Then apply the YAGNI principle (You Ain't Gonna Need It) and KISS (keep-it-simple-smartguy).
Think twice before you implement anything like what you're asking about doing in your question.
Your best Option, IMHO, is using a scripting engine and storing scripts in the database.
Alternatively you could put the code in a dll and put that dll in the database. There is code for loading a dll from a resource into ram and processing it so it can be used as if it was loaded using LoadLibrary, e.g. in dzlib. I don't really know whether works with any dll and in which versions of Windows, but it does with the ones I tried.
I am working on a WPF 4.0 application which uses the Microsoft Office Interop to read and write to Excel files. But I am facing a scenario where I need to read/write data from/to Excel files on systems that do not have Office installed.
This is somewhat a repeat of this question. The only reason I reposted this question because the earlier post was 3 years old and I just wanted to know if there is a better way available right now.
The requirement is that I need to write into and save the file as .xls/.xlsx formats and read from the same. I am supporting both the format using the Interop right now.
Buying a license is not an option.
Installing Excel is not an option.
Need to Support Read/Write from .xls/.xlsx formats.
Easy to Implement as I am a little behind schedule. Would not be able to give a lot of time on implementation.
Need a solution that is trustworthy and robust, meaning it should be something that you have used personally or have a good feedback about.
Would prefer a solution that can cater to both read/write and can support both .xls/.xlsx formats. If something like this doesn't exist, can use different solutions, but all the above points would apply to them individually.
Don't need suggestions, but more like guidance.
Please do not vote to close this question as duplicate as the other ones do not give a concrete solution. There are too many suggestions. I need a solution that you are confident about as this application goes into final build soon and if I do not get any robust solution to this, we might end up releasing as is.
If you can live without the xls-support (only xlsx) then you should most definitely look at the OpenXML SDK:
http://www.microsoft.com/en-us/download/details.aspx?id=5124
I doesn't require Excel or any extra license, you can do both read and write, I would say that it is robust and it comes with the Productivity Tool which is great. On the other hand, the API isn't that intuitive and you can't process .xls-files.
I suggestyou ExcelPackage: Office Open XML Format file creation
http://excelpackage.codeplex.com/
I'm looking to create a very small cataloguing app for personal use (although I'd open source it if I thought anyone else would use it). I don't want a web app as it seems like overkill to have an application server just for this - plus I like the idea of it being standalone and sticking it on a USB stick.
My Criterea:
Interface must be simple to program. It can be curses-style if that makes it easer to code. My experience with ncurses would suggest otherwise, but I'd actually quite like a commanline UI.
Language doesn't really matter. My rough order of preference (highest first):
Python
C
C++
Java
I'll consider anything linux-friendly
I'm thinking sqlite for storage, but other (embeddable) suggestions welcome.
Has anyone done this sort of thing in the past? Any suggestions? Pitfalls to avoid?
EDIT:
Ok, it looks like python+sqlite is the early winner. That just leaves the question of which ui library. I know you get tkinter for free in python - but it's just so ugly (I'd rather have a curses interface). I've done some GTK in C, but it looks fairly un-natural in python. I had a very brief dabble with wxwidgets but the documentation's pretty atrocious IIRC (They renamed the module at some point I think, and it's all a bit confused).
So that leaves me with pyqt4, or some sort of console library. Or maybe GTK. Thoughts? Or have I been too hasty in writing off one of the above?
I would definitely recommend (or second, if you're already thinking it) - python with sqlite3. It's simple, portable and no big db drivers. I wrote a similar app for my own cataloguing purposes and it's doing just fine.
I vote for pyqt or wx for the GUI. (And second the Python+sqlite votes to answer the original question.)
I second (or third) python and sqlite.
As far as suggestions are concerned:
If you're feeling minimally ambitious, I'd suggest building a very simple web service to synchronize your catalog to a server. I've done this (ashamedly, a few times) for similar purposes in the past.
With sqlite, backups can literally be as simple as uploading or downloading the latest database file, depending on the file's timestamp.
Then, if you lose or break your flash drive (smashed to pieces, in my case), your catalog isn't lost. You gain more portability, at least 1 backup, and some peace of mind.
I'm hearing more and more about domain specific languages being thrown about and how they change the way you treat business logic, and I've seen Ayende's blog posts and things, but I've never really gotten exactly why I would take my business logic away from the methods and situations I'm using in my provider.
If you've got some background using these things, any chance you could put it in real laymans terms:
What exactly building DSLs means?
What languages are you using?
Where using a DSL makes sense?
What is the benefit of using DSLs?
DSL's are good in situations where you need to give some aspect of the system's control over to someone else. I've used them in Rules Engines, where you create a simple language that is easier for less-technical folks to use to express themselves- particularly in workflows.
In other words, instead of making them learn java:
DocumentDAO myDocumentDAO = ServiceLocator.getDocumentDAO();
for (int id : documentIDS) {
Document myDoc = MyDocumentDAO.loadDoc(id);
if (myDoc.getDocumentStatus().equals(DocumentStatus.UNREAD)) {
ReminderService.sendUnreadReminder(myDoc)
}
I can write a DSL that lets me say:
for (document : documents) {
if (document is unread) {
document.sendReminder
}
There are other situations, but basically, anywhere you might want to use a macro language, script a workflow, or allow after-market customization- these are all candidates for DSL's.
DSL stands for Domain Specific Language i.e. language designed specifically for solving problems in given area.
For example, Markdown (markup language used to edit posts on SO) can be considered as a DSL.
Personally I find a place for DSL almost in every large project I'm working on. Most often I need some kind of SQL-like query language. Another common usage is rule-based systems, you need some kind of language to specify rules\conditions.
DSL makes sense in context where it's difficult to describe\solve problem by traditional means.
If you use Microsoft Visual Studio, you are already using multiple DSLs -- the design surface for web forms, winforms, etc. is a DSL. The Class Designer is another example.
A DSL is just a set of tools that (at least in theory) make development in a specific "domain" (i.e. visual layout) easier, more intuitive, and more productive.
As far as building a DSL, some of the stuff people like Ayende have written about is related to "text parsing" dsls, letting developers (or end users) enter "natural text" into an application, which parses the text and generates some sort of code or output based on it.
You could use any language to build your own DSL. Microsoft Visual Studio has a lot of extensibility points, and the patterns & practices "Guidance Automation Toolkit" and Visual Studio SDK can assist you in adding DSL functionality to Visual Studio.
DSL are basic compilers for custom languages. A good 'free and open' tool to develop them is available at ANTLR. Recently, I've been looking at this DSL for a state machine language use on a new project . I agree with Tim Howland above, that they can be a good way to let someone else customize your application.
FYI, a book on DSLs is in the pipeline as part of Martin Fowler's signature series.
If its of the same standard as the other books in the series, it should be a good read.
More information here
DSL is just a fancy name and can mean different things:
Rails (the Ruby thing) is sometimes called a DSL because it adds special methods (and overwrites some built-in ones too) for talking about web applications
ANT, Makefile syntax etc. are also DSLs, but have their own syntax. This is what I would call a DSL.
One important aspect of this hype: It does make sense to think of your application in terms of a language. What do you want to talk about in your app? These should then be your classes and methods:
Define a "language" (either a real syntax as proposed by others on this page or a class hierarchy for your favorite language) that is capable of expressing your problem.
Solve your problem in terms of that language.
DSL is basically creating your own small sublanguage to solve a specific domain problem. This is solved using method chaining. Languages where dots and parentheses are optional help make these expression seem more natural. It can also be similar to a builder pattern.
DSL aren't languages themselves, but rather a pattern that you apply to your API to make the calls be more self explanatory.
One example is Guice, Guice Users Guide http://docs.google.com/View?docid=dd2fhx4z_5df5hw8 has some description further down of how interfaces are bound to implementations, and in what contexts.
Another common example is for query languages. For example:
NewsDAO.writtenBy("someUser").before("someDate").updateStatus("Deleted")
In the implementation, imagine each method returning either a new Query object, or just this updating itself internally. At any point you can terminate the chain by using for example rows() to get all the rows, or updateSomeField as I have done above here. Both will return a result object.
I would recommend taking a look at the Guice example above as well, as each call there returns a new type with new options on them. A good IDE will allow you to complete, making it clear which options you have at each point.
Edit: seems many consider DSLs as new, simple, single purpose languages with their own parsers. I always associate DSL as using method chaining as a convention to express operations.
I have a couple of questions regarding VBScript and ASP Classic:
What is the preferred way to access an MS SQL Server database in VBScript/ASP?
What are best practices in regards to separating model from view from controller?
Any other things I should know about either VBScript or ASP?
If you haven't noticed, I'm new at VBScript coding. I realize numbers 2 & 3 are kind of giant "black hole" questions that are overly general, so don't think that I'm expecting to learn everything there is to know about those two questions from here.
ADO is an excellent way to access a database in VBScript/Classic ASP.
Dim db: Set db = Server.CreateObject("ADODB.Connection")
db.Open "yourconnectionstring -> see connectionstrings.com"
Dim rs: Set rs = db.Execute("SELECT firstName from Employees")
While Not rs.EOF
Response.Write rs("firstName")
rs.MoveNext
Wend
rs.Close
More info here: http://www.technowledgebase.com/2007/06/12/vbscript-how-to-create-an-ado-connection-and-run-a-query/
One caveat is that if you are returning a MEMO field in a recordset, be sure you only select ONE MEMO field at a time, and make sure it is the LAST column in your query. Otherwise you will run into problems.
(Reference: http://lists.evolt.org/archive/Week-of-Mon-20040329/157305.html )
I had to walk away from my PC when I saw the first answer, and am still distressed that it has been approved by so many people. It's an appalling example of the very worst kind of ASP code, the kind that would ensure your site is SQL-injectable and, if you continue using this code across the site, hackable within an inch of its life.
This is NOT the kind of code you should be giving to someone new to ASP coding as they will think it is the professional way of coding in the language!
NEVER reveal a connection string in your code as it contains the username and password to your database. Use a UDL file instead, or at the very least a constant that can be declared elsewhere and used across the site.
There is no longer any good excuse for using inline SQL for any operation in a web environment. Use a stored procedure -- the security benefits cannot be stressed enough. If you really can't do that then look at inline parameters as a second-best option... Inline SQL will leave your site wide open to SQL injection, malware injection and the rest.
Late declaration of variables can lead to sloppy coding. Use "option explicit" and declare variables at the top of the function. This is best practice rather than a real WTF, but it's best to start as you mean to go on.
No hints to the database as to what type of connection this is -- is it for reading only, or will the user be updating records? The connection can be optimised and the database can handle locking very efficiently if effectively told what to expect.
The database connection is not closed after use, and the recordset object isn't fully destroyed.
ASP is still a strong language, despite many folks suggesting moving to .NET -- with good coding practices an ASP site can be written that is easy to maintain, scaleable and fast, but you HAVE to make sure you use every method available to make your code efficient, you HAVE to maintain good coding practices and a little forethought. A good editor will help too, my preference being for PrimalScript which I find more helpful to an ASP coder than any of the latest MS products which seem to be very .NET-centric.
Also, where is a "MEMO" field from? Is this Access nomenclature, or maybe MySQL? I ask as such fields have been called TEXT or NTEXT fields in MS-SQL for a decade.
Remember to program into the language rather than program in it. Just because you're using a limited tool set doesn't mean you have to program like it's 1999.
I agree with JasonS about classes. It's true you can't do things like inheritance but you can easily fake it
Class Dog
Private Parent
Private Sub Class_Initialize()
Set Parent = New Animal
End Sub
Public Function Walk()
Walk = Parent.Walk
End Function
Public Function Bark()
Response.Write("Woof! Woof!")
End Function
End Class
In my projects an ASP page will have the following:
INC-APP-CommonIncludes.asp - This includes stuff like my general libraries (Database Access, file functions, etc) and sets up security and includes any configuration files (like connection strings, directory locations, etc) and common classes (User, Permission, etc) and is included in every page.
Modules/ModuleName/page.vb.asp - Kind of like a code behind page. Includes page specific BO, BLL and DAL classes and sets up the data required for the page/receives submitted form data, etc
Modules/ModuleName/Display/INC-DIS-Page.asp - Displays the data set up in page.vb.asp.
Echoing some ideas and adding a few of my own:
1) Best way to access the database would to abstract that away into a COM component of some sort that you access from VBScript.
2) If you really wanted to you could write the controller in VBScript and then access that in the page. It would resemble a Page Controller pattern and not a Front Controller that you would see in ASP.NET MVC or MonoRail
3) Why are you doing this to yourself? Most of the tooling required to do this kind of work isn't even available anymore.
AXE - Asp Xtreme Evolution is a MVC framework for ASP classic
There are some attempts at making test frameworks for asp:
aspUnit is good, but no longer maintained.
I saw a sample on how to make your own one a few months back.
The example used nUnit to call functions against the website for automatic testing.
I think i got it off here (my line is borked so I can't check)
On number 2, I think you have a few options...
1) You can use COM components developed in VB6 or the like to separate some of your business logic from your UI.
2) You can create classes in VBScript. There is no concept of inheritance and other more advanced features are missing from the implementation, but you can encapsulate logic in classes that helps reduce the spagehtti-ness of your app. Check out this: https://web.archive.org/web/20210505200200/http://www.4guysfromrolla.com/webtech/092399-1.shtml
I agree with #Cirieno, that the selected answer would not be wise to use in production code, for all of the reasons he mentions. That said, if you have just a little experience, this answer is a good starting point as to the basics.
In my ASP experience, I preferred to write my database access layer using VB, compiling down to a DLL and referencing the DLL via VBScript. Tough to debug directly through ASP, but it was a nice way to encapsulate all data access code away from the ASP code.
way way back in the day when VBScript/ASP were still ok
I worked in a utility company with a very mixed DB envrionment, I used to swear by this website: http://www.connectionstrings.com/
#michealpryor got it right
I've been stuck building on ASP, and I feel your pain.
1) The best way to query against SQL Server is with parameterized queries; this will help prevent against SQL injection attacks.
Tutorial (not my blog):
http://www.nomadpete.com/2007/03/23/classic-asp-which-is-still-alive-and-parametised-queries/
2) I haven't seen anything regarding MVC specifically geared towards ASP, but I'm definitely interested because it's something I'm having a tough time wrapping my head around. I generally try to at least contain things which are view-like and things which are controller-like in separate functions. I suppose you could possibly write code in separate files and then use server side includes to join them all back together.
3) You're probably coming from a language which has more functionality built in. At first, some things may appear to be missing, but it's often just a matter of writing a lot more lines of code than you're used to.
Also for database access I have a set of functions - GetSingleRecord, GetRecordset and UpdateDatabase which has similar function to what Michael mentions above