I am looking for information on the best practices or project layout for software that uses SQL embedded inside VB.NET or C#. The software will connect to a full SQL DB. The software was written in VB6 and ported to VB.NET, we want to update it to use .NET functionality but I am not sure where to start with my research. We are using Visual Studio 2005. All database manipulations are done from VB.
Update: To clarify. We are currently using SqlConnection, SqlDataAdapter, SqlDataReader to connect to the database. What I mean by embed is that the SQL stored procedures are scripted inside our VB code and then run on the db. All of our tables, stored procs, views, etc are all manipulated in the VB code. The layout of our code is quite messy. I am looking for a better architecture or pattern that we can use to organize our code.
Can you recommend any books, webpages, topics that I can google, etc to help me better understand the best way for us to do this.
I am looking for a better architecture or pattern that we can use to organize our code
...
topics that I can google
Take a look at DAL (Data Access Layer) for database transactions
Here is a link to a StackOverflow question posted by someone who is facing a similar situation
Creating a Class Library in VB.NET
When you google "How to create DAL", you will see list of how to create a DAL as well as what DAL is.
And here is a nice article that shows how DAL fits into an N-Tier achitecture
What is n-Tier Architecture?
Webopedia: N-Tier Application Architecture - Shows a nice graphical representation
It sounds like you're looking for a grand theoretical book that is written for one very specific case, i.e. what is the best practice for managing our current spaghetti SQL code framework, and I don't know that I've ever seen a book or document that describes that.
That being said, we converted several applications from VB6 to C# a few years back and were in the same place. Other than breaking apart certain modules so that their organization made more logical sense overall, our applications are essentially the same as they were, just rewritten in C#. I don't personally like the idea of separating SQL code from the function for which it was written (which is sort of what it sounds like you're trying to do); in general, if we have a function that needs to hit the database, we create a SqlCommand and, optionally, a SqlDataReader, set the CommandType to StoredProcedure and add the parameters, then perform the call and consume the result, doing with it whatever the function was programmed to do.
I don't know that that is the best way to do it, but it works for us.
Would it be possible to convert it to using LINQ? It's safer than converting it to using regular old embedded SQL statements.
In addition to what Sung Meister said, you should also consider moving the SQL from the VB.NET code into Stored Procedures, and then call the SPs from the VB.NET code (the Data Access Layer). It provides many advantages.
Related
Having quite a lot of SQL queries, many of them ad-hoc-ones, a database has grown a bit messy. I have two problems :
Hard to keep many different views/sproc's in good order when only using names to structure them
Subqueries (views that calls other views, in 2-4 levels) adds to the structure mess and are hard to maintain
Now I like to get a better structure in my database and/or in my C# code (could be java/python/ruby/whatever). How?
Should I use "schemas" in SQL to separate views in different areas? Like namespaces.
Should I avoid having lot of TSQL in the database altoghether and instead keep the querying to my C#? That would move the database logic closer to the rest of the system, and would be much easier to maintain and keep in code versioning, but at the same time I appreciate being close to the data, to keep performance good (with the help of SQL profiler).
Any other suggestion?
Update: the database and the c#-projects are a few years old and has grown, and will continue to grow over time (different areas of functionality) + new projects will be added. I need to clean it up in a good way, or change strategy.
Ok, why is complexity in your C# code easier to manage than complexity in your TSQL?
It must be that either your tooling for or knowledge of C# is superior. You should address that.
You can adopt naming conventions, and organise files to aid in this task. Use development environments to support TSQL and source control. Make sure you can deploy new and upgraded database schemas programmatically. Just like you should with C#.
Without knowing the details of your project I can't specify an exact structure.
How should you decide where logic should be implemented?
At a generic level this is simple.
The database should perform set based operations that can benefit from the use of indecies on your data. This code is easier to write in TSQL and other set based query languages.
Your application/business layer should perform row level operations, ideally in a stateless (Shared/static) fashion. This code is easier to write in c#, and other procedural languages.
Scaling database servers is more difficult than a stateless application layer. How do you maintain synchronization across multiple machines?
There is no exact right answer. There are just many shades of grey. The best solution will be based on your requirements. Start with the MS Defacto VS 2013, SQL 2012, C#, EF6 and embellish or simplify from there.
I just found this article by Martin Fowler "Domain Logic and SQL" http://martinfowler.com/articles/dblogic.html .
Performance first?
"One of the first questions people consider with this kind of thing is performance. Personally I don't think performance should be the first question. My philosophy is that most of the time you should focus on writing maintainable code. Then use a profiler to identify hot spots and then replace only those hot spots with faster but less clear code"
Maintainability
"For any long-lived enterprise application, you can be sure of one thing - it's going to change a lot. As a result you have to ensure that the system is organized in such a way that's easy to change. Modifiability is probably the main reason why people put business logic in memory [= application code instead of TSQL]."
Encapsulation
"Using views, or indeed stored procedures, provides encapsulation only up to a point. In many enterprise applications data comes from multiple sources, not just multiple relational databases, but also legacy systems, other applications, and files. [...] In this case full encapsulation really can only be done by a layer within the application code, which further implies that domain logic should also sit in memory."
Is using strongly typed dataset is good.
Currently I am working on a project developed using VB.Net in Visual Studio 2010.
Previously they were using Sql queries directly into SqlCommand of System.Data.SqlClient, but then after i shifted everything to Strongly Typed DataSet and started using TableAdapters every where..
Now i just wanna ask that is this way is good for a project...
Or Should i shift back to old ones using Just SqlCommands
Or Is there any way to make Sql DataBase in a good way because its an ERP and most of the code is for Data Access..
We use strongly typed datasets all the time now.
After shifting to this behaviour it felt really bad to have SQL-querys in code instead of having it done by the table adapter. But there is a bit overhead with datasets so I guess booth ways are good for different solutions.
Its really nice to have intellisence on all fieldnames and if you change a tableadapter so it returns something different you get design-time errors everywhere where you need to change the code to reflect the change, instead of finding out runtime when the customer is running the program.
There are so many win win-things with strongly typed datasets so I'll never go back.
Table adapters .... make a lot of mess with bigger databases, also updating the table structure also causes confusion.
I would recommend to use some auto code generators for the CRUD Operations.
To me your old pattern looks better than switching altogether to table adapters and strongly typed datasets.
If you ever want to move your data across the wire to other platforms (silverlight, web services, wcf services, etc), then using any kind of dataset will box you into a corner.
The way that we have resolved this is to have classes whose list of properties match the database exactly. To move the data in and out of the database, we use reflection to either match stored procedure parameters or generate dynamic SQL statements, depending on the circumstance and platform.
When a database table is changed, the developer making the change is also responsible for updating the class structure and vice-versa.
In order to reduce the amount of hand-coding required, we use the code generation capabilities of CodeSmith to generate classes from the database and create the basic implementations of our standard add/update stored procedures that require field enumeration.
As an added benefit, this approach removes the tight link between the database and business object structure. We are able to use our same data access code and business object classes against SQL Server, Oracle, Sqlite, and SqlServerCE databases. This code is used to create applications in Windows, PocketPC, Web, iPad, and Android apps; all of the mobile apps use local databases specific to the platform, but using the common data access code.
It is a bit more work to setup initially, but it will pay significant dividends in the long run.
I am primarily a web developer, mostly working with PHP, MySQL, and JavaScript. I was recently contacted by a local Sheriff's Office (small town word of mouth, nerds are always needed) to digitize a 4 page monstrosity of a form... because nobody could read the handwriting of the deputies.
The catch here is that this is a small town department and, while they are fancy enough to carry computers in the field, they are not connected to the Internet. Visual Basic was the first solution that came to mind and I have been scrambling to learn the basics. I am confident in my ability to organize the content of the form and perform any necessary validation but I am unsure where to begin in terms of storing each report locally (database) and printing the end result.
Another matter that makes things complicated is the fact that they want the end result to look exactly the same as the original form, only typed instead of hand written.
So, to sum things up, here are the questions I have:
There seem to be several options for databases in VB 2010 Express. What is the best option for LOCAL storage of records?
It looks as though the best way to format the form the exact way they want it to look with populated data would be to create a form within the application with just this content on it. Is this the best solution or might there be a better way - possibly outputting to another file? And if the data is put on another form, how would I go about printing it?
Many thanks!
The word "best" is of course subjective, so instead I'll give you some pros and cons for a database.
SQL Server Express is a really awesome database to work with that acts almost exactly like the big paid version. Some high-level things like replication and encryption aren't supported but you don't have a need for that probably. I've built many websites that target it with zero performance problems. The downside of SQL Server Express is that you need to install it on every machine and it pretty much needs to be running all the time. It doesn't "weigh" a whole lot but its still going to be running in the background 24/7. If you create an installer from within Visual Studio/VB Express (which you should) you can check it as a prerequisite and the installer will pretty much take care of it for you. As a major security target you are opening a potential for security issues which you should be aware of.
SQLite would another great choice, there's some great .Net wrappers available. If you're used to using SQL Server or MySql you might find SQLite limiting but you get used to it. SQLite doesn't have a "database engine" and its goal is to be a very lightweight open source SQL database system.
The third option that I'd recommend is just writing to an XML file. Simple, no engine, no tables, no third-party whatever, just raw text that anyone can parse if something breaks. EDIT And VB.Net has some wonderful built-in XML syntactic things such as XML literals:
Dim MyXml = <Person>
<FirstName><%= txtFirstName.Text %></FirstName>
<LastName><%= txtLastName.Text %></LastName>
</Person>
For the form generation, I'd recommend using something like iTextSharp. (Free but make sure you check that the license matches yours.) Take their actual PDF Form (or create a PDF of theirs), use Acrobat or something similar to turn it into a "PDF Form" and then just use iTextSharp to fill in the form. There's a bunch of support on this site if you've got any questions about it.
A project I am currently employed with will have some time soon to improve and specialise a product that is currently in use.
We may have about 4 man weeks spare in which we could replace the typed datasets that are in use.
The project is currently written in Vb.Net and we will definitely not have time to replace this code with C#.Net, although we would like to.
My question is what would you suggest as a replacement for the typed datasets.
I have currently suggested nHibernate as I have worked with Hibernate before and loved it.
Linq to SQL has been discounted.
So if you can suggest something else/better or highlight what advantages or disadvantages with regards to our current time constraints please do!
Considering your time constraints Linq to SQL (despite being deprecated) would have been ideal. While NH or EF4 are more complete and flexible ORM solutions they do require more consideration of mappings than does a simple drag and drop from the Server Explorer connection mapping onto LINQ to SQL designer and simple instantiation of a DataContext object.
If you don't have the time to get everyone up to speed on an ORM with a future why eliminate the typed datasets at all?
Performance wise they are probably close to identical to what you would be able to get out of an ORM. The benefit of replacement would be maintainability and developer pleasure, both of which would be <warning:shameless plug for personal preference> accompanied by a C# rewrite at the same time...
I think NHibernate is a good choice to replace typed datasets, I just successfully did that on a project I was on recently. I wouldn't do a "big bang" approach though. I would write new features using NHibernate and maintain old features using typed datasets. Once the new features are working well with NHibernate and you have the appropriate usage patterns in place, I would carefully transition the typed dataset and sproc code to use NHibernate instead. The speed at which you do the replacement doesn't really matter, just move at a comfortable pace.
Big bang is always a highly risky approach and incremental progress is easier for everyone to swallow.
I honestly don't see a compelling reason to switch a project in production from VB.NET to C#, there are so few meaningful differences and it helps to have VB.NET (in addition to C#) experience on your resume.
I would not encourage use of LinqToSql nor would I encourage use of Entity Framework 3.5. EF 4 may be a reasonable option using the same incremental approach.
So I'm having a head against the wall moment and hoping somebody can come help either remove the wall or stop my head from moving!!
Over the last 3/4 weeks I've been investigating ORM's in readyness for a new project. The ORM must map to an existing, large and ageing SQL database.
So I tried Subsonic. I really liked v2 and v3 after modding to work nicely with VB and named schemas in SQL was running OK. However, its lack of flexibility of having separate entity properties names vs column names had me pulling my hair out (sorry Rob).
I tried Entity Framework but I found like others it lacking in certain areas.
So I bit the bullet and tried nHibernate but after a week or so getting it working how I liked (with help from Codesmith to generate classes/hbms for me) I'm frustrated with the time it takes to startup (build a config object), despite trying a number of tricks to reduce this time.
I'm essentially after building a DAL class that I can share between apps and websites. Am I barking up the wrong tree? For a legacy project with 100s of tables should I go back to ado.net and use DTOs? Aarrgh!
Sorry for the ranty style of question. I don't have much hair left and I'd like to keep what I have!!
Thanks in advance, Ed
PS. I should add that I know SQL very well and not scared of getting my hands dirty to write fast queries. If anything I don't need to be hid from SQL
ORM let's you:
To map table rows to objects, that are the the workable pieces of object oriented programming.
To automatically navigate through object relationships
To easily add, edit and remove table rows
To query the database in a more intuitive way as you don't have to think of joins (this one will depend on the ORM and the query method)
To transparently handle L1 and L2 cache.
All of the above would have to be handled by hand if you werent using ORM.
PS: I agree to Dmitry as to the startup time of NHibernate (see question comments). Besides, did you try Fluent NHibernate? Fluent NHibernate is impressively easy. I couldn't believe my eyes when I first mapped a database. It's even easier than proprietary ORMs like DevExpress XPO.
The biggest benefit of an ORM tool is that it will help you layer your application correctly. Most project nowadays use a Data Layer to connect to the database. You start from the ORM tool to produce classes that correspond to your database objects. Then you define an interface using these methods. All persistence code uses the methods of this interface. This way the business logic layer is only coupled to this higher-layer interface and needs to know nothing about the database. In fact there should be no dependency on ADO.NET or even NHibernate.
Another advantage of ORM tools is that you de-couple your application from the database server. You could change the db engine and still use the same code. Also there isn't only the complexity of the SQL that the ORM hides from you. It can also help you with transactions logic and connection pooling.
I'd say that for new projects an ORM tool is a necessity. For legacy projects it isn't so much beneficial, unless of course you have the time/money to start from scratch.
In my experience, most ORMs end up being way more complex than SQL. Which defeats the entire purpose of using them.
One solution I'm enthusiastic about is LINQ2SQL. It excels as a thin layer about stored procedures or views. It's really easy to use and doesn't try to hide SQL.
There are basically two questions here:
What's great about ORMs? There are similar questions on Stackoverflow. See:
What are the advantages of using an ORM?
Is everyone here jumping on the ORM band wagon?
How can I improve NHibernate startup time? See:
http://ayende.com/Blog/archive/2007/10/26/Real-World-NHibernate-Reducing-startup-times-for-large-amount-of.aspx
http://nhforge.org/blogs/nhibernate/archive/2009/03/13/an-improvement-on-sessionfactory-initialization.aspx