Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 424
  • Last Modified:

Managing Data in a .NET web application

Hey Experts,

I have an ASP.NET MVC 3 web application. I am looking to have multiple pages access a common data source, and have that data managed by an admin page. Please tell me the most architecturally correct way to do this, and the easiest way to do this.

I have looked into creating a service for this, and would prefer to use XML as a means to store the data, as there isn't a complicated schema or huge hierarchies of data or large amounts of data.

Do I really need to create a service? Should I? I'm worried because it seems like anyone on the web could possibly access the service I create and add shows to my website... I'm not sure how to secure a service so only the website can talk to it either.

To reiterate: Please tell me the most architecturally correct way to do this, and the easiest way to do this without managing the data (querys or xml mods) directly in the website, but rather through a class, service or other that has methods I define to do it for me.

Please give me your thoughts, and thanks in advance, and help!

  • 2
  • 2
1 Solution
You asked:

I have an ASP.NET MVC 3 web application. I am looking to have multiple pages access a common data source, and have that data managed by an admin page. Please tell me the most architecturally correct way to do this, and the easiest way to do this.

To that effect, you just need a database.  Create your database using access or use CodeFirst framework and then connect to it in your web.config:

    <add name="MyDbContext" connectionString="Data Source=|DataDirectory|MyDatabase.sdf" providerName="System.Data.SqlServerCe.4.0" />

Open in new window

See this tutorial (either C# or VB) for operating a CRUD (create, read, update, delete) system in MVC 3:

Alan WarrenCommented:
Totally agree with @EMB01, you create the db schema first, maybe even knock up a quick prototype using some rapid application development (RAD) tool such as Ms Access first. Don't spend too much time on the user interface (UI), just get the engine ticking over nicely. This will also give you some idea of what sort of db structure will work.

That done, you handball it to the client, as your user needs analysis and outline of requirements for taking the concept global; stress this is just a prototype, clients are often tempted to use the prototype to begin with, this should be discouraged, but not stomped upon.

You then gotta sell the global project bigger picture to the client:
From what I can glean from your initial outline, you will need 4 interfaces. Hypothetically lets say one for a crew of evangelistic lead finders to populate a list of prospective clients; a client table.

Another interface for a team of fast talking, ground shaking, deal making, go getting sales reps; a sale table.

Another interface for the logistics crew, the go anywhere, anytime guys, who work out the product delivery and timeline nightmare, a delivery table.

Finally the boss gets a slice of the interface, he just wants to keep his finger on the pulse, likes to be able to check his logs (merged client/sales/delivery data) from anywhere, assigning reps to clients and delivery options to sales teams, basically he needs the flexibility to move the pieces around the board at anytime from anywhere in this world; to do that he needs real-time logistic reports, he doesn't need a table for that, all calculated data. But what he really likes to do is fire off invoices from his deck chair via his iPod while cruising the carribean on his yacht, he might even settle his account with you; an account table.

tblClient, tblSale, tblDelivery, tblAccount.
each client can and hopefully will have many sales, one client links to many sales.
each sale can and should cater from multiple delivery options, one sale links to many deliveries.

The account table is a bottleneck, a pulling together of the other tables into an historical record which can be used for invoicing and analysis. In the db heirarchy, the account table is top of the heap, but in reality it can't exist without the other tables (dependancies), it only exists for historical reasons. As such I wouldn't force any referential integrity on the account table, leave it stand alone, it links to nothing and everything, we can tap into any or all of the other tables dynamically at any time.

By now you have completely won the boss over, he's invited you out on the yacht next Sunday to discuss costing and timeline, at which time you would emphasise the negligible cost of an asp .net hosting packing complete with a sql db catalog; while also emphasing the obvious flexibilities of such a system, being priceless; your costs hardly worth considering for such a valuable commodity.

Don't know about the need for MVC and dynamic services, I'd go for four interfaces (possibly single .aspx pages) to begin with, the hierarchy being controlled by an asp .net roles provider. Four roles, leads, sales, delivery and admin, when a leads member logs into the asp .net membership server via the login page or MVC dynamic service if you prefer, they get the leads menu, sales members get the sales menu, delivery members get the delivery menu, the boss get's everything and more...

Enough rambling ...

jeffiepooAuthor Commented:
EMB01, do I have to manually add the connection string, or is there a way to have Visual Studio do this for me? I don't know how to associate a database I created in server explorer to a connection string..

I think you can do it in VS but I recommend doing it manually so you learn.

To connect to a local db (one your your computer), do this:

<add name="YourDbContext" connectionString="Data Source=|DataDirectory|MyDatabase.sdf" providerName="System.Data.SqlServerCe.4.0" />

To connect to a remote db (not on your computer), do this:

<add name="YourDbContext" connectionString="Data Source=YourRemoteServersIpAddress\SQLEXPRESS;Initial Catalog=YourDatabase;User Id=YourUserName;Password=yourPassword;" providerName="System.Data.SqlClient"/>
jeffiepooAuthor Commented:
Used Entity Framework. Your comment got me on the right track.

Featured Post

Become an Android App Developer

Ready to kick start your career in 2018? Learn how to build an Android app in January’s Course of the Month and open the door to new opportunities.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now