Does SQL SERVER just be used to storage and let the application do all the work
-
Hi, i want to know if with this business logic layer that had been sounding for a while, i just must use my sql server to do the storage work and let me application do all the operations involved in
the daily basis.
I'm willing to hear your answers
Thank you.
-
it's not an all-in-the-db or all-in-the-application kind of thing.
it's a mixture of both doing their parts to make sure the data is good.
generally you make sure your data has constraints as well, which end up enforcing some business logic.
examples might be some fields cannot be null, like firstname, lastname,invoice number; foreign keys making sure some data exists before child data can be related to it,
do you have any specific quesitons?
Lowell
--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible! -
using System.Collections.Generic;
using System.Data.Linq;
using System.Data.Linq.Mapping;
namespace Demo
{
#pragma warning disable 0169 // disable never used warnings for fields that are being used by LINQ
[Table( Name = "BookCategories" )]
public class Category : IBookCollection
{
[Column( IsPrimaryKey = true, IsDbGenerated = true )] public int Id { get; set; }
[Column] public string Name { get; set; }
private EntitySet<Book> _books = new EntitySet<Book>();
[Association( Name = "FK_Books_BookCategories", Storage = "_books", OtherKey = "categoryId", ThisKey = "Id" )]
public ICollection<Book> Books {
get { return _books; }
set { _books.Assign( value ); }
}
}
}
As you can see, what we used to do in the managment studio, now we can do it in VS, letting just the storage work to the database. What i want to know is if this is the new paradigm or we have to avoid this practice, beacuse i had investigate and Microsoft seems to support this kind of practice.
-
well, whether you use a datatable like that on the fly, or a strongly typed dataset, the constraints should be the same, creating a duplicate structure of what exists in SQL; makes it easy to work with ,and allows you to use the GUI/interface to validate and raise errors , or intercept any errors prior to pushing the data back to the SQL Server.
you shouldn't , for example, have constraints in your Dataset that do not exist in your actual SQL table...they should be the same.
That's why you'd use the server explorer to drop your tables into a typed dataset, inherit all those constraints and structure the easy way.
without the identical constriants, once it's on the server, someone could directly update the data, and when you bring the data from the server into your DataSet, the data could raise exceptions due to those alllowed-on-the-server changes, but invalid in the dataset.
Lowell
--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible! -
Thanks for your time Lowell, i would keep that in mind.
rvargas
Viewing 5 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply