|
Sometimes you just have to make absolutely sure it is a string. And since it is OO programming they could have done this:
lastItem.Value.ToString().ToString().ToString().Trim()
just to make really, really sure.
|
|
|
|
|
I like that! But you know, sometimes you want to be a little more sure than other times. Therefore, I propose the that following method be added:
public static string ConvertToString(object objectToConvert, ulong howSureDoYouWantToBeThatItIsString)
{
string temp = objectToConvert.ToString();
for(ulong n = 0; n < howSureDoYouWantToBeThatItIsString; n++)
{
temp = temp.ToString();
}
return temp;
}
Now ain't that a piece of beauty!
|
|
|
|
|
I like that! I wanted to see how many times that is possible to be looped: 18,446,744,073,709,551,615. That's a few loops.
I figure, on my 2GH machine, that's approximately 272.19712525667353 years. (probably double that because 1 flop per loop and 1 flop per string conversion)
double years = (double)((ulong.MaxValue / int.MaxValue) / (3600 * 24)) / 365.25;
flop = "FLoating point OPeration"
Is it 1 or 2000 flops per string conversion for a 2000 character string?
PS Yes, I'm having fun with people without an understanding of precision too.
|
|
|
|
|
I didn't know about IsNullOrEmpty, and apparently we both didn't know about IsNullOrWhiteSpace which removes the need for Trim.
|
|
|
|
|
Maybe he was thinking of the 'String' theory!
Yeah, I know, it's a groaner.
Attempting to load signature...
A NullSignatureException was unhandled.
Message: "No signature exists"
|
|
|
|
|
Hi guys
im new here but i tough i would share this example of code i encountered a couple months back
in one class
Select field1,field2,field3
From table1
Where type="EDU"
the only fucntion using this result set was coded like this
If(field1=cond1 and field2=con4 and Active=true)
do something
else If(field1=cond1 and field2=con2 and Active=true)
do something
else If(field3=cond10 and field2=con2 and Active=true)
do something else
this went on for like 9 time
now someone added another If lower down in the code but forgot the Active=true hense causing a bug ! now after searching to make sure that the Selqct wasent used anywhere else(the name was a dead give away but you never know)
First off
Select field1,field2,field3
From table1
Where type="EDU" AND Active=True
PLEASE add this AND ... just reducing the result set will bost this application speed has its database was Huge
as for the rest we where not allowed to modify working code but come on 9 inbricked iff with some repeating coditions ....
modified 6-Feb-12 21:04pm.
|
|
|
|
|
Is it really necessary to select the same field THREE times?
|
|
|
|
|
Lol yeah sorry for the type O
i edited the post
Cheers
|
|
|
|
|
|
Jtai wrote:
Select field1,field2,field3
From table1
Where type="EDU"
When I read the code, I thought it was a pity that Active wasn't in the DB so you could restrict the number of lines based on Active. Then I thought, don't even run the logic if Active isn't true. As I continued reading, I realized the real condition. Did you drop the Active check in the code along with modifying the select?
If it's still a large # of rows being read, you might want to include your condition checks in the selection criteria. Also, hopefully, you are really running a sproc to get your data.
Here's an example of using 4 condition checks with very different selection criteria. If two condition checks overlap then the data produced would overlap. The table had 5K rows in it, the selection had 39 rows in it.
declare @tbl table (Cond int, sTotID int, stot1 int, stot2 int, stot3 int)
insert into @tbl
values (1,-1, 20, -1, 49), (2, 203148, -1, -1, -1), (3, -1, 15, 29, -1), (4, -1, 25, 32, -1)
SELECT TOP 1000 Cond, TotID
,NumbRecs
,tot1
,tot2
,tot3
FROM dbo.ThreeNumberSum
JOIN @tbl on (sTotID = -1 or sTotID = TotID) AND (stot1 = -1 OR stot1 = tot1)
AND (stot2 = -1 OR stot2 = tot2) AND (stot3 = -1 OR stot3 = tot3)
Your code could just check 1 value to match all the multiple conditions. Here is an extract of all the rows:
Cond TotID NumbRecs tot1 tot2 tot3
1 202749 32 20 27 49
... middle number 28-30
1 203149 208 20 31 49
1 203249 184 20 32 49
1 203349 128 20 33 49
1 203449 56 20 34 49
1 203549 8 20 35 49
1 203649 8 20 36 49
2 203148 424 20 31 48
3 152940 24 15 29 40
3 152941 40 15 29 41
3 152942 32 15 29 42
3 152943 48 15 29 43
3 152944 8 15 29 44
3 152945 8 15 29 45
4 253228 28956 25 32 28
4 253229 49698 25 32 29
... last number 30-35
4 253236 595694 25 32 36
4 253237 529858 25 32 37
... last number 38-48
4 253249 8 25 32 49
|
|
|
|
|
tecgoblin wrote: It's surprising how many people try to create their own solutions to problems which already have established and well-behaving solution :S.
In the spirit of this comment I wanted to introduce a new standard - the DAO Framework. Problem: "Some day you may wish to change databases." Solution: "Create a generic database access framework to ease migration."
Example:
Firstly, define a DBConst file as follows:
public class DBConst {
public static String SELECT = "SELECT";
public static String WHERE = "WHERE";
public static String AND = "AND"
etc
}
Then create an interface: SQLFactory as follows:
public interface SQLFactory {
public String createSQL(String[] selectors, String[] whereClauses);
}
If I remember correctly, now all you have to do is (Not in the original this was a class, I invented using interfaces - yay me):
public interface MyTable {
public static String TABLE_NAME = "MyTable";
public static String COL_1 = "Col1";
public static String COL_2 = "Col2";
}
Okay, we're nearly ready to write some code:
public class MyTableDao {
public MyObject selectObject(String selector) {
String[] columns = {MyTable.COL_1, MyTable.COL_2);
Object[] types = {DbTypes.DATE, DbTypes.INTEGER};
String[] whereClause = {MyTable.COL_1};
Object[] whereValues = {selector};
MySqlFactory sqlFactory = new MySqlFactory();
String sql = sqlFactory.createSql(columns, whereClause);
PreparedStatement ps = connect.prepareStatement(sql)
MySqlInjector.injectValues(ps, new Object[] {selector});
ResultSet rs = stmt.executeQuery(query);
MyObject[] objs = MyObjectFactory.getObjects(rs, columns, types);
}
Yeah, I think that was it. I'm writing from memory from 5 years ago so forgive if errors.
Key standards:
* List the columns to retrieve
sb.append(DbConsts.SELECT).append(" ").append(COL).append(,) ...
* List the types of the columns so an object factory can retrieve the right type
if(type[0]==DbTypes.INTEGER) rs.getInt();
* List the WHERE clauses
sb.append(DbConsts.WHERE).append(" ").append(clauses[0]...
I forgot about the static object factories until now. I suspect the SQL factories were static rather than implementations of an interface. It was more by program by convention.
The rest of the implementation is left as an exercise for the reader.
Can we stop all this nonsense with Hibernate now please?
|
|
|
|
|
|
Absolutely not. No joke. Can't remember/was never sure whether people accepted it because of the designer's standing in the company or because they didn't realise.
|
|
|
|
|
I had to do stuff like that in the 90s when my company was playing musical chairs with SQL vendors.
Our server side apps ended up being able to run seamlessly on SQL Server, Sybase and Oracle. That probably doesn't sound like a big deal now, but driver standardization wasn't so far along when NT 3.51 was king.
Under the hood, the Microsoft code does similar tasks to what is suggested here...
|
|
|
|
|
Seems legit...
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}
|
|
|
|
|
Very good idea in 2005, but we can now forget all this old rubbish, as we have LINQ.
Hallelujah !!
Yes I did have to look up the spelling..
|
|
|
|
|
I'm not sure it ever was a good idea to be honest. This was in 2005 (+- 2 years) and I joined this company after two years of using Hibernate. I was using it for batch analysis and complex relationships without too much issue (caching being an exception)
I still think that writing out the sql by hand would have made better reading/maintenance and in fact used to convert these DAOs to manual ones when I could.
This is an example of "future-proofing" that definitely made things worse.
Next example would have to be 9-10 layers (DAO, BO, Service, Process, Application, Remoting, Command, Action, User Validation) when 3 or 4 would have done. Or maybe passing a user id in every method signature in case we needed to apply security. Or perhaps a utility class with 100+ unrelated methods. Or was it the 3000 line classes. No, I remember - creating copy books for the mainframe.
|
|
|
|
|
I agree sometimes less is more.
I am currently writing a DB connected WPF app using Entity Framework and Linq for DA. I started out using Stored Procedures with EF, and then abondoned the idea due to currupted Entity Data Objects when re-adding edited SPs. I now just use LINQ for all DA, and find it much less stressful than dealing directly with the database myself.
Saying that creating dynmanic entity connections was a bit problematic.
As for security, I am using singleton patterns to store commonly used global properties. This cuts down on DB access.
I'm finding the whole dev process is much faster this way, and easier to structure.
|
|
|
|
|
Yes, so now we have people making some new abstraction to what doesn't need abstracted. The urge of in house programmers to design a framework is strong. Why use a single class to wrap something if one can use four or five? And while we are at it, we can make it easy to do things we never do anyway. If we get on a roll, perhaps the architect who clearly doesn't get writing code will adopt a new standard of crap.
|
|
|
|
|
The DAO that can be implemented, is not the true DAO.
|
|
|
|
|
Am I even partially responsible for this?
Well, I've seen this type of "DAOs" around in many legacy ASP.NET projects I've worked with. It's strange how the newest one had been written during the last months of 2010.
modified 6-Apr-21 21:01pm.
|
|
|
|
|
This only appears to be a good idea when you are sleep deprived and working on your project at 4am. That's why I drink more coffee. I had to support code like this a few times. Good luck if you are trying to debug the query, especially if the person who wrote it used column indexes instead of column names when referencing the result set.
|
|
|
|
|
Turf Monster wrote: Good luck if you are trying to debug the query
I was reading through the comments and thinking exactly this before encountering your post. (Shudders at the memory).
|
|
|
|
|
At first I was prepared for a flame against the ancient-of-days DAO from Microsoft, which was the data access interface for Access. At least that interface (and still is) useful in a wide variety of applications where the coder is also the database interface guy.
The only time I've ever developed such an abstract interface was for a code transition from the use of Raima's dbVista network-model database to relational DB2 for OS/2. But then, most of the code I write these days is either for SQL Server or for Access but never for both at the same time. I know there are many valid reasons for using LINQ and Entity Framework, particularly if you have a large project where the coders have little or no ability to add or modify the functionality of an existing database, and also for data storage mechanisms that you want to access as if they were relational when in fact they are anything but - and boy am I glad not to be working in projects like that at the moment
|
|
|
|
|
Works for me.
I write mostly desktop applications using C# (VS2008). Over the last several years I've built a utility library that abstracts SQL access into a very simple set of routines that I use in all my applications. The work is all done. I can very simply connect and interact with SQL databases without having to forever call up a help reference or reconstruct a connection string. The library was fun to develop and debug and now sits there waiting for me to use it when developing another application.
>>It's surprising how many people try to create their own solutions to problems which already have established and well-behaving solution<<
Yeah ... I developed it myself because I wanted a SIMPLE way to do all that. The .Net Framework has tons of features built-in but nothing approaching the simplicity of what I built myself. This is surprising? Not to me. Mature developers have always abstracted "library" code for their own use so they could avoid re-inventing the wheel in SOMEONE ELSE's image.
-Max
|
|
|
|
|