I'm a former classic ASP programmer and sometimes PHP programmer writing my first ASP.NET application. I'm loving the much-improved ADO.NET functions, but I'm feeling the need to write a database class. Partly I want to consolidate the code that actually interacts with the database, and partly I want to reduce what feels like repetition.
A simple database class is not hard to do, but I'm using parameterized queries as one of my security measures. I'm struggling with how to incorporate this into a class. I wrote a function to return the datatype of a column in the database by passing in the table and column name, but I can't think of a robust way to obtain the table and column name from the SQL query.
My design for the class was to have a Query() function for selecting, and an Execute() function for insert/update/delete. (Not opposed to having more public functions, but didn't want to get ahead of myself.) Both functions take a SQL string and a SortedList for the parameters. It might be possible to get the column name by finding the parameter name in the SQL string and looking in front of the equal sign. Likewise, it should be fairly simple to get the table name when the query is insert, update, or delete, because you only work with one table at a time. The big concern is selecting, because there could be one or more joins, inner selects, etc.
Am I headed in the wrong direction? Anything I'm not thinking of that could make my life easier or more difficult? Anybody written a class for this in any language that could offer some advice?
Don't reinvent the wheel. Look into nHibernate or LINQToSQL (or LINQToEntities) for your ORM needs.
Would second the call to find a tried and tested wheel that works for you, especially if this is your first foray into aspnet... there will be plenty else to keep you busy.
Would add a suggestion for SubSonic, which is perhaps a little lighter than nHibernate, but it really depends on the nature of your project, they are both great tools, and both have saved me months of work over the last few years.
I think since this is your first experience in ASP.NET you would be well advised to look into Linq to SQL. Do some tutorials so you get a feel for how it works before you try to code any Linq queries.
The only reasons I can think of to NOT use Linq to SQL in your case would be if you are not using SQL Server (or need to support other DBs either now or in future), or you cannot use .NET 3.5 runtime for some reason.
Good luck
It sounds to me like your "simple database class" is hiding too many details from the classes that need to use it.
I've written classes that contain a SqlCeEngine and expose methods like "LookupDescription(String Code)" ... I think that kind of design is something you should be looking into. And, consider looking into LINQ. It has a lot to offer.
Related
I am trying to get the CostCenter, MainAccount and Department starting from the LedgerDimension field in the LedgerJournalTrans table.
I found this but I am lost.
http://ax2009developer.blogspot.ro/2014/02/how-create-customize-look-up-for.html
In fact, for this task, I have implemented only queries in AOT. Is there any way to join some tables and get there without taking the X++ approach?
Financial dimensions in AX 2012 are far more complicated than in previous versions.
You should start with this white paper: http://download.microsoft.com/download/4/E/3/4E36B655-568E-4D4A-B161-152B28BAAF30/Implementing_the_Account_and_Financial_Dimensions_Framework_AX2012.pdf
You'll find the tables involved and their relations.
By the way, I recommend you not to build your own queries. As the model is really versatile, it will be first tricky to build your query, then they will not be performant.
You need to use the APIs as they are already built and also as they use the system global object cache to cache data, as the model is not set for fast queries.
Unfortunately, I don't believe there is an easy way to do what you want with queries only and X++ is the way to go.
You could, in theory, create a view that you would use in your query objects. It would have tables DimensionAttribute, DimensionAttributeValueSet DimensionAttributeValueSetItem, and DimensionAttributeValue I think. And multiple instances of each in some cases.
Then in your view, you'd set ranges with your different Attribute names. This is fairly complex, but you could repeatedly use it on any query. I could see value in it for sure, but if you've not worked much with dimensions, you have some learning to do to get that working.
This is entity framework:
var department = _context.Departments
.Include(dep => dep.Employees.Select(emp => emp.ContactTypes))
.SingleOrDefault(d => d.Id == departmentId);
Here I expect one department to be returned containing all related employees and all contact types for each employee.
This is ormlite servicestack:
I have no idea. When I look at the docu/samples: https://github.com/ServiceStack/ServiceStack.OrmLite
They write:
Right now the Expression support can satisfy most simple queries with a strong-typed API. For anything more complex (e.g. queries with table joins) you can still easily fall back to raw SQL queries as seen below.
I have seen there is a JoinSqlBuilder class but I do not think it can return nested collections.
Maybe what I want is not possible but maybe I can do a compromise like get all employees for the departmentId. Then I inmemory foreach the employees and fetch all contact types for a certain employeeId. Creating the hierarchy and assigning the lists would still be my job.
But I hope there is a shorter solution.
What would also be fine is when the query however it might look like return an object (Dynamic?) with 3 flat properties: Department, Employees, ContactTypes and assign thoese properties to my DTO.
Ok, please don't take this as a definitive answer, but more just my take on the situation (I don't use service stack very much) however...
When I first started to use EF many years ago, I came across a similar situation, where the references just would not load. Like you I was faced with the likely hood of having to enumerate the individual collections myself and write a lot of extra code for an operation the ORM should be able to handle easily.
What I ended up doing, was to use auto-mapper, which basically reduce all the multiline loops I had everywhere to a single line mapping statement.
Granted, I still had to do one mapping statement for each linked property, but it reduced the code I had to write, and more importantly got me up and running until EF improved, or I found a better way of doing things.
Let me stress, I'm not proposing this as an answer, and it's a bit big for a comment, I'm simply suggesting shifting your thought in a different direction, that may help a better solution come to the surface.
I am currently working to rework the data system of our application. Basically, it is designed so that people can add all the custom fields they want, with only a few constant/always-there fields.
Our current design is giving us plenty of maintenance problems. What we do is dynamically(at runtime) add a column to the database for each field. We have to have a meta table and other cruft to maintain all of these dynamic columns.
Now we are looking at EAV, but it doesn't seem much better. Basically, we have many different types of fields, so there would be a StringValues, IntegerValues, etc table... which makes things that much worse.
I am wondering if using JSON or XML blobs in the database may be a better solution, specifically because in most use cases, when we retrieve anything out of these tables, we need the entire row. The problems is that we need to be able to create reports for this data as well.. No solution really makes custom queries look easy. And searching across such a blob database will surely be a performance nightmare when reports are ran.
Each "row" needs to have anywhere from about 15 to 100(possibly more) attributes/columns associated with it.
We are using SQL Server 2008 and our application interfacing with the database is a C# web application(so, ASP.Net).
what do you think? Use EAV or blobs or something else entirely? (Also, yes, I know a schema free database like MongoDB would be awesome here, but I can't convince my boss to use it)
What about the xml datatype? Advanced querying is possible against this type.
We've used the xml type with good success. We do most of our heavy lifting at the code level using linq to parse out values. Our schema is somewhat fixed, so that may not be an option for you.
One interesting feature of SQL server is the sql_variant type. It's fully supported in .NET and quite easy to use. The advantages is you don't need to create StringValue, IntValue, etc... columns, just one Value column that can contain all the simple types.
This very specific type favors the EAV option, IMHO.
It has some drawbacks though (sorting, distinct selects, etc...). So if you want to use it, make sure you read all the documentation and understand its limit.
Create a table with your known columns and "X" sparse columns using a sequential name such as DataColumn0001, DataColumn0002, etc. When there is a definition for a new column just rename a column and start inserting data. The great advantage to the sparse column is it is indexable.
More info at this link.
What you're doing is STUPID with a database that doesn't support your data type. You should work with a medium that meets your needs which include NoSQL databases such as RavenDB, MongoDB, DocumentDB, CouchBase or Postgres in RDMBS to name several.
You are inherently using the tool in a capacity it was neither designed for, and one it specifically attempts to limit you from achieving success. NoSQL database solutions frequently use JSON as an underlying storage because JSON is inherently schemaless. Want to add a property? Sure go ahead, want to add a whole sub collection? Sure go ahead. NoSQL databases were in part, created specifically to remove rigid schema requirements of RDBMS.
2015 Edit: Postgres now natively supports JSON. This is a viable option for RDBMS. My answer is still correct that you need to use the correct tool for the problem. It is a polygot persistence world.
When is it appropriate to create a helper class for a sql server database using the asp.net framework? Basically I'm trying to create a minature wiki (with multiple pages) and storing all of the data/strings for a specific page into a table on it's own.
Always and Never.
Always, because you want good separation of your data tier from your business logic and presentation tiers (or model and view, or whatever framework you use). Make sure you're thinking of it in these terms, too.
Never, because this is already done for you, on several levels. There are numerous ORMs out there, including Linq-to-sql, NHibernate, Entity Framework, and more. More than that, what is ADO.Net but a set of classes to encapsulate your server?
Well it could be appropriate to return a single instance of a DbConnection object - that way you only specify how to connect to the DB in one spot.
You may find it useful to have a base class for your ADO layer which provides these generic methods to deal with the ADO (part of the .NET framework for connecting to SQL server).
You could have a helper method to populate an object from a DataReader using reflection too.
Also for putting parameters together to send to a SQL command or Stored procedure.
Hope you find this helpful. :)
It's heavily dependant on your project.
For code clarity, and your own sanity, you might find it easier to make a wrapper class for all of your Database manipulation. This way you can have the rest of your code work with native objects, rather than the contents of a DataReader.
Just my advice, but hopefully helpful.
I just started working on an asp.net / C#.net application that is going to call a number of different procedures. The -only- thing these procedures do is create database table views, and the only thing I want to do is to store the information in variables. Then pick out which columns I want to convert to JSON, and then make a JSON string. I've actually written code for that in C#.net already, which is smaller, but since I switched to asp.net mvc I'm a little unsure if I should keep it or go with the whole Linq thing.
I checked out the Linq --> SQL drag & drop functionality, and that instantly created about 200 lines of code with set & get methods and everything.
So my question is, is it still worth using Linq even for just extracting data? Eventually this data will be fed to a javascript timeline, which is where I was told MVC would be highly useful with regards to Ajax functionality.
Since you are only using LINQ-to-SQL for data retrieval, I can't think of a single reason NOT to fully utilize it. I've been working on an MVC 1.0 project since last April. During that time, I've had to quickly become familiar with a number of technologies, LINQ-to-SQL being one of them. Get comfortable with it, and also look at the repository pattern...you will be very content and things will go relatively smoothly.
Now, when you get to INSERTs and UPDATEs, things are going to get a little more sticky. LINQ-to-SQL is still up to the job, but you'll need to understand how things work internally a little better. I highly recommend "Pro LINQ (Language Integrated Query) in C# 2008" by Joseph C. Rattz, Jr. The sections covering LINQ-to-SQL easily take up over a third of the book with detailed examples.
As far as the JSON objects go, LINQ-to-SQL's biggest contribution is that it allowed me not to have to worry about creating specialized views or stored procedures just to handle those one-off-types of data retrievals. My current project has a database of 65 tables...NO stored procedures. I can do filters, unions, multi-level joins...and it's all maintained in the application. Sweet...
Yes, it's totally worth it!
LINQ2SQL provides you a great subsurface to retrieve and save data to.
However, you'll need to implement your own Repository Pattern as you dig deeper into ASP.NET MVC.
And during the implementation of the Repository and the required (and even custom / webapp-state based) Queries, you'll be very glad to have all the power available at your fingertips that LINQ provides.
LINQ only adds to the available toolkit you can lean on when creating code. Even if you are using LINQ in a trivial way now, implement it, get familiar with it, and take advantage of the power it gives you both on this project and future projects.
Linq2Sql is quiet good for creating select queries. As it is appearing that you need to create JSON objects from database views it will be quiet useful