I'm totally rewriting the question..
I'm new to ASP.Net, and trying to develop a website that is
- simple, but has many grids
- uesrs will update/delete/insert data on grids/tables through the website
Other facts would be:
- MS SQL Server 2008
- .Net Framework 4.0
- intranet
- thin client
- the website should be secure - no hole for sql injection etc.
- 10 users
- Database tables are already defined
- no stored procedures are defined yet, but will be soon
- all database related functions will be done through stored procedures.
Can you please suggest which approach would be the best in my situation to communicate with the database securely. Entity Framework? LinqToSQL?, WCF? or ASP.Net Web Service?
I was thinking of Entity Framework as suggested below, but here are more questions related to EF:
1. Do I need WCF for EF?
2. if DB tables are already structured, do I need to rebuild DB tables along with EF?
3. is EF has more secure than ASP.Net Web Service?
4. Functions are fully done by stored procedures, EF is a good choice?
Why would you use a webservice?
You can check just communicate with the database through Enterprise Library, LINQ2SQL or Entity Framework
As architecture, I understand MVC, MVC2 or MVC3 frameworks that you can use to build your application.
As grids you may use MSSQL-side query paging or client side jQuery Datatables paging..
Entity Framework would be a great choice for this. You don't need any web services. EF 4 has a great thing called Code First, but in your case, your tables are done and I wouldn't suggest it. My recommendation would be for you would be to use N-Tier architecture to design your site. Using N-Tier will maintain a separation of your data layer, business rules and your UI. Your data layer should be a separate class project that should only be accessed by your business rule layer. Your UI should never communicate with the data layer and only communicate with your business rule layer. If you want to go even further, program your site to an interface using something like IoC and Ninject. This will ensure a true separation of data and UI.
Maybe the simpliest way is to use ASP.NET Dynamic Data
Related
I am currently struggling to find a way to migrate to a new database schema for a database shared by multiple applications, while keeping applications working with the old schema intact.
There are multiple applications performing CRUD operations on the shared database, using a self-written ORM-like library. The main problems I see with this architecture are:
Each application implements its own business logic with a lot of code being redundant or code which should do the same in every application but is implemented differently and therfore hard to maintain
Since each application works directly with the ORM-library the other applications cannot know when some data was changed by another application without monitoring/polling the database for changes
The ORM-library does implement only limited concurrency, no transactions and is relatively slow
To solve the redundancy/inconsistency problems I am thinking about implementing a layered architecture.
Service Layer
Business Layer
Data Access Layer
Database
The applications then communicate with a SOAP web service on the service layer.
The service layer uses the business layer to perform validation and apply business logic. The business layer uses the data access layers repositories.
I am hoping to be able to also use the business layer in the client applications, with another repository implementation, which does not access the database directly but via the SOAP web service.
To solve the other problems I was hoping to use Entity Framework instead of the selfmade ORM-library. But the schema of the database is made in a kind of generic way. Meaning for each machine added to the database (database stores facility data) several machine specific tables are added. This results in redundant tables, named [machinename]_[tablename]. As far as I know, Entity Framework or any other ORM cannot deal with that (its poor design anyway, probably meant to speed queries up).
The plan would be to migrate to another database schema, but the problem with that is that all the applications using the database need to be changed to use the new schema/SOAP web service. This cannot happen from one day to another therefore it would be best if I can keep some of the applications unchanged, but still work on the only one database. And then later deal with reimplementing the other applications to use the web service.
I already thought about using views to simulate the old schema, so that the old applications can still work with the changed schema, but unfortunately the selfmade ORM does not support working with views.
I don't expect anyone to present me a solution but rather some basic approaches and/or ideas to improve the overall architecture of the system.
I have one project which have 8 modules.
some of then is developed in VB.net,asp.net,C# windows forms,asp.net
Now we have situation that we are not able to manage this modules.
so need to re-write this application using new technology like aps.net mvc,
web api etc.
But we have big problem we have lot of logic in stored procedure
(80% ~ 90%) the we are not come out of sp. we are using EF for database Communication but we are not able to design domain Model in persistence layer
and we need DDD (domain driven design)
So how we design application architecture so this will support Web,desktop application and also for Mobile. :)
Stored procedure business logic is inherently not going to be DDD. If you are insisting that you keep stored procedures, then you will not get DDD.
That being said, wrapping web api wrappers around stored procedures should allow you to leverage them in the various ways you specify:
How to return values to Web API Controller from a stored procedure in DBContext
http://sivakumarparameswaran.blogspot.com/2014/02/how-to-invoke-stored-procedure-in-web.html
I have a strange situation. I have created a data model visually and generated a database from it. This project is referenced by two projects:
ASP .NET application.
WinForms application.
The ASP .NET application deals directly with the database while I need the WinForms application to interact with the database via the Web application.
I have created a page called API.aspx and use HTTP POST to send values and get results in XML.
However, since the WinForms application still needs to use the data model classes, I am running into issues using them without creating a database object.
What is a good strategy to use in this scenario?
If you have implemented your code with loose coupling (See the Repository Pattern), then you could create a database stub that will return dummy data (or in memory data) until you are ready to plug in the actual EF framework.
This is generally good practice to create a clean separation of concerns.
This sounds like a candidate for an SOA implementation, rather than having the windows forms app communicate directly with the web application:
http://en.wikipedia.org/wiki/Service-oriented_architecture
http://msdn.microsoft.com/en-us/library/aa480021.aspx
I recently started learning about ASP.Net MVC and its various features MVC_3_MUSIC_STORE +
CODE .
It looks very structured and simple to understand.
I was reading about enterprise applications and how they are layered/tiered in different sections
(logical/physical)
I was wondering(for learning ) how to do separate(convert) the above MVC_3_MUSIC_STORE into n-tier or 3 tier application (since we already have a working example) in order to have a clean separation of concerns.
I don't have much prior experience in this.
What changes would be required?
What will be different DTO(s) or POCO(s) that would be needed?
The above example uses POCO entities around from controller to views.
Would it remain same, assuming EF Code first is used.
Also i was wondering what changes will be required if WCF Webservice is introduced as a data access layer. i.e.Instead of retrieving data from DAL ,Clients will request data to and from WCF Webservice. Client can be Web app or WinForms or Sliverlight app.
( [DAL <--> WCF WS] <--> N CLIENTS)
Would be interesting to know about various approaches.
Example code would be helpful and/or examples for same.
Edit 1 - Added
One of the things I noticed was when i move the model classes from Model folder to new project "MYMODEL" I will have to again add reference to "System.ComponentModel.DataAnnotations" and "System.Web.Mvc" in new model project?
How can this be avoided? How can these validations be moved to Business layer?
Edit 2
Looking for something similar to this
Advice For A Newbie About N-Tier Applications
Normally the only change that will be required is that you will provide an implementation of the repository (DAL layer) which will call a WCF web service to fetch the domain models from instead of some EF DataContext talking directly to the database. A change completely transparent to Controllers and Views.
ADO.NET Data service is the next generation of data access layer within applications. I have seen a lot of examples using it directly from a UI layer such as Silverlight or Ajax to get data. This is almost as having a two tiered system, with business layer completely removed. Should DAL be accessed by the Business layer, and not directly from UI?
ADO.NET Data Services is one more tool to be evaluated in order to move data.
.NET RIA Services is another one. Much better I would say.
I see ADO.NET Data Services as a low level services to be used by some
high level framework. I would not let my UI talk directly to it.
The main problem I see with ADO.NET Data Services has more to do with
security than with anything else.
For simple/quick tasks, in a Intranet, and if you are not too pick with your
design, it can be useful. (IMO)
It can be quite handy when you need to quickly expose data from an existing database.
I say handy, but it would not be my first choice as I avoid as much as I can
the "quick and dirty" solutions.
Those solutions are like ghosts, always come back to haunt you.
ADO.NET Data service is the next generation of data access layer within applications
I have no idea where you got that from! Perhaps you're confusing ADO.NET Data Services with ADO.NET Entity Framework?
One shouldn't assume that everything Microsoft produces is of value to every developer. In my opinion, ADO.NET Data Services is a quick way to create CRUD services, which maybe have a few other operations defined on the entity, but the operations are all stored procedures. If all you need is a database-oriented service, then this may be what you want. Certainly, there's relatively little reason to do any coding for a service like this, except in the database.
But that doesn't mean that ADO.NET Data Services "has a place in the overall design" of every project. It's something that fills a need of enough customers that Microsoft thought it worthwhile to spend money developing and maintaining it.
For that matter, they also thought ASP.NET MVC was a good idea...
:-)
In my opinion other answers underestimate importance of ADO.Net Data Services. Though using it directly in your application brings some similarity to two tiered system , other Microsoft products such as .Net RIA Services , Windows Asure Storage Services based on it. On the contrary to the phrase in one of the answers "For simple/quick tasks, in a Intranet, and if you are not too pick with your design, it can be useful" it may be useful for public websites including websites in ASP.Net MVC.
Dino Esposito describes the driving force for Ado.Net Data Services in his blog
http://weblogs.asp.net/despos/archive/2008/04/21/the-quot-driving-force-quot-pattern-part-1-of-n.aspx
"ADO.NET Data Services (aka, Astoria)
Driving force: the need of building richly interactive Web systems.
What's that in abstract: New set of tools for building a middle-tier or, better yet, the service layer on top of a middle-tier in any sort of application, including enterprise class applications.
What's that in concrete: provides you with URLs to invoke from hyperlinks to bring data down to the client. Better for scenarios where a client needs a direct|partially filtered access to data. Not ideal for querying data from IE, but ideal for building a new generation of Web controls that breath AJAX. And just that."