Develop Reference

Best approach for migrating database schema of shared database

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.

Good architecture to shift a WPF desktop application to Client Server technology

I have a working WPF application that works on a single PC. I have used SQL server database, Entity Framework to communicate with database
and RDLC reporting in the application. Now the requirement has arrived to make this application work on the local company network where multiple users (normally around 25 at max) will access application depending upon there roles and permissions set. I did some R&D on this and used primarily the architecture mentioned here http://www.codeproject.com/Articles/434282/A-N-Tier-Architecture-Sample-with-ASP-NET-MVC-WCF, and after doing so, I have made a paper design/architecture of the application that will look like this
A WCF service running on a high end server within the company network
GPC.Service itself - defines the protocol to connect to the service
and all other necessary information
GPC.Algorithm - will be the main business logic layer that will
contain the logic and will be interface to the clients for calling
the database layer methods
GPC.Persistance - will have actual database interaction methods like
fetching/storing/updating/deleting records in the database
GPC.Data - This will contain the edmx schema for the Entity
Framwework
GPC.Entites - This will contain the entities of the database schema
and addional partial classes
**
Clients:
The client will a WPF Application based on MVVM pattern for now (may be in future we will need to move to the Web application but not required for now). Main components of the application are:
Import from excel: Currently all data is in Excel files. All that
data needs to be imported into the system.
Edit/Update/Delete: Once data is imported, allow interface to user
to edit/update/delete records
Generate reprots (using RDLC for this)
Users/Roles management etc.
Shared:
This is a library that contains differnet miscelenious classes like code to read excel file, Handle errors, Collections that will be bind to the UI etc.
DB context: Will be created in a using statement inside the Persistance layer for each method to ensure no stale information is left.
Does this architecure follow the n-tier architecture and is it flexible? What improvements are required in this and please guide me how to improve whatever issues are there. I want to make sure this is a good architecture before I go ahead and change my existing application.

It seems like your are on the correct path however you may be over engineering in some areas.
I think to a large degree the EntityFramework deals with the Entities, Data and Persistence layers for you. Implementing them yourself may be overkill unless you are looking to ultimately replace EntityFramework with some other ORM system.
You are eluding to SOA (Service Orientated Architecture) here with your GPC.Services library. Here you need to look at how you can break down your service layer into one or more atmoic services which will serve the client application. There are a number of ways of going about this and would depend largely on how you plan to use the service layer going forward. Take a look at RESTful services which breaks down the services layer nicely and will guide you into building neat atmoic services. Check out the Asp.net Web API for this.
I think what you are looking for in your GPC.Alogrithms library is really a domain model. A domain model encapsulates all your business logic and allows you to perform state changes on your objects via public functions which you expose. With this in mind the layers of the system would appear as follows:
Persistence (EF) -> Domain Model -> Service Layer -> DTO (Data Transfer Objects) -> Client
The DTO objects mentioned above would be a set of POCO (Plain Old C# Objects) which are responsible for delivering data to and from your client. You need this since serializing and desalinizing your domain objects will become problematic due to back references and other encapsulation issues. Putting DTO's in place will enforce a context boundary which is once of the tenets of SOA - "Boundarys are explicit", see this for more info on soa
With respect to the client side it seems like you are on track. What you may want to do is refactor you current client application so that all data queries are consolidated into a single layer. So when the time comes you will just replace that layer with the service implementation.

this makes perfect sense. (try to build it TDD style)
in order to make your life a bit easier with the client versions management consider to use ClickOnce installer to enforce the latest version installations on your users computers (this headache will be gone once you will move it to be a web app).

ASP.Net Web Application Architecture

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

Converting ASP.Net MVC to N-Tier

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 services their place in overall design

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."