I have a developed a application that is gonna to be used at multiple places.
So how should i maintain one database for all?
Or is there only one way of using remote database for this software.
If i use remote database, i am facing problem with loading controls in forms.
Please Suggest Solution.
Thanks
Typically you'd design a system leveraging multi-tiered architecture, which often consists of:
Front-end user interface
A database back-end
Middle tier/business layer that let's your web pages access the database and provides additional business logic (perhaps a web service?)
You don't give much to go on as far as details go, but it seems like you have several physical locations that need to access a single database. So you can:
Develop an (web or desktop) application that handles the front-end UI and the middle tier (which will access data and do other stuff)
Develop an application that handles only front-end UI, but calls a web service that accesses a database and does other stuff. In this case, you may have several locations with different front-end applications that consume the same centralized web service.
Related
I'm a bit confuse when the user is trying to login into the Silverligh Business application.
In my database, I've got two tables called Students and Teachers, and I've got a view called UsersView where I do an union between these two tables (and this view or query, has just as attribute Id).
I need to use this view in my silverlight business application to verify if the user exists. I've seen that many projects are using WFC RIA Services, in fact I was thinking to call directly to my database but I'm really confuse.
Can someone tells me if it's necessary to login through AuthenticationBase?
Silverlight cannot call directly to a database since it's a client side application. It HAS to go through an intermediary WCF service, or you can use WCF RIA services to get some functionality out of the box. A silverlight business application template should come with two projects, a silverlight one that produces a client side .xap and a web project. If you go to properties on the silverlight app it should show a RIA services link to the web project. If you run it, it should (if I am not mistaken) create a temp database using a sql express instance to login and validate users. So, long story short. Yes, you have to login using AuthenticationBase. Logins can only happen on the server. So you have to wait for the silverlight app to communicate to the server, validate against the db and then submit a response through RIA. Hope that helps.
I need to insert some fields of data (example: Customer Phone etc) from outside(Externally) into the already developed/working (Installed) ERP Invoicing application. When I open the ERP application those fields should automatically appear in the application for the particular order in the form. Currently the the external data is entering manually into the ERP application. I need to integrate from the different place to ERP Application using some another application, like C# Windows Application. We can access ERP database. How can I approach this for the solution to the problem using C#/windows application externally.
I am not sure what approach you used for Integration, but as it seems from your question that you have enough knowledge about their database structure and flow of data you can directly write to the tables to reflect the updated information in that ERP.
But this is not a recommended approach to integrate with any ERP, by directly interacting to their database tables, even if you have access to them and you very well understand the data flow. Integration to any ERP should only be done through API's provided by that ERP, or through some connectors available in market which are recommended by the ERP vendor.
You should look for an API or interface your ERP application provides to integrate external applications and/or modules, otherwise, if you have enough knowledge of how this ERP works and underlying database structure, than you can directly interact with the data...
I am looking for a messaging/eventing framework that will allow changes in one application to be subscribed to by other applications. My situation is I have an ASP.NET web application that allows users to perform CRUD operations. I also have multiple unknown applications that are used to synchronize data in our application with data in a clients application. What I would like to do is allow our ASP.NET app to send out a notification that Company A has been created. I would like the client application to be able to "subscribe" to the event from our application. I basically want to get away from the need to modify our ASP.NET code each time a new client app is needed. What sort of technologies exist to handle this sort of situation?
Check out NServiceBus: www.nservicebus.com
Excellent framework for handling communication between different business services.
I'm building a traditional .NET MVC site, so I've got a natural 3-tier software architecture setup (presentation in the form of Views, business layer in the controller, and data layer in the models and data access layer).
When I've deployed such sites, it usually goes either on one server (where the web site and db live), or two servers (a web server and a separate db server).
How does one go about a 3-server architecture (WEB, APP, and DB)? Would the web server just have the presentation (e.g. the physical View/aspx pages), the app server would hold the config file and bin folder, and the db server would remain as is?
My question is essentially, can you simply move the /bin and all app logic onto a separate server from the presentation views? If so, how do you configure the servers to know where to look? If there's a good primer somewhere or someone can give me the lowdown, I'd be forever indebted.
MVC is not a 3-tier architecture. Not every solution needs to be 3-tier or n-tier, but it is still important to understand the distinction. MVC happens to have 3 main elements, but those elements do not work in a "tiered" fashion, they are interdependent:
Model <----- Controller
\ |
\ v
---- View
The View depends on the Model. The Controller depends on the View and Model. These multiple dependency paths therefore do not function as tiers.
Typically a 3-tier solution looks like:
Data Access <--- [Mapper] ---> Domain Model <--- [Presenter/Controller] ---> UI
Presenter/Controller is somewhat optional - in Windows Forms development, for example, you usually don't see it, instead you have a "smart client" UI, which is OK too.
This is a 3-tier architecture because each of the 3 main tiers (Data, Domain, UI) has only one dependency. Classically, the UI depends on the Domain Model (or "Business" model) and the Domain Model depends on the DAL. In more modern implementations, the Domain Model does not depend the DAL; instead, the relationship is inverted and an abstract Mapping layer is injected later on using an IoC container. In either case, each tier only depends on the previous tier.
In an MVC architecture, C is the Controller, V is the UI (Views), and M is the Domain Model. Therefore, MVC is a presentation architecture, not a system architecture. It does not encapsulate the data access. It may not necessarily fully encapsulate the Domain Model, which can be treated as an external dependency. It is not tiered.
If you wanted to physically separate the tiers then it is usually done by exposing the Domain Model as a Web Service (i.e. WCF). This gives you improved scalability and a cleaner separation of concerns - the Domain Model is literally reusable anywhere and can be deployed across many machines - but comes with a significant up-front development cost as well as an ongoing maintenance cost.
The server architecture mirrors the 3-tier diagram above:
Database Server <----- Web Services <----- Application
The "Application" is your MVC application, which shares a Domain Model with the Web Services (through SOAP or REST). Web Services run on a dedicated server (or servers), and the database is, obviously, hosted on its own server. This is a 3-tier, 3-server architecture.
In some circles, I have seen this discussion phrased as the difference between n-tier and n-layer where a "layer" in this context potentially represents another machine. In order to have a middle layer using this definition, it must be hosted. For example, if you had a service layer which the presentation layer called to get its data, then the service layer could be on a different machine than the presentation or database. However, that service layer is hosted either as a windows service or as a web service. I.e., there is a process listening for requests on that machine. Thus, you cannot simply move the bin folder to different machine and hope to have this work. I would look at WCF (Windows Communication Foundation) for creating these types services.
ASP.NET MVC does not help you in setting up a 3tier system. This is realy only a frontend pattern.
The main issue you have to solve implementing a multi tier system is the transport of objects from one server to another. You have to find a way to serialize all objects depending on the transport channel. This gets slow and development gets more complicated.
There are reasons to have a separate app-server: You might have logic in it that other application need or the app-server might have different permissions than the Webserver. But its hard to imagine a high traffic website, where all requests lead to a call to a remote app - server.
Next logical scale up would be two web servers and one database server.
Eventually after adding many web servers it might be worth adding a service layer.
You might also want to add a distributed cache, session state server, email server, and other specialized servers at some point too as you scale.
So your questions seems to be ...
"can you simply move the /bin and all app logic onto a separate server from the presentation views?"
If I am understanding correctly, I believe the files in your bin folder will be the compiled code behinds for your asp.net pages. If that is the case then, no, I believe they need to be on the same machine as the asp pages.
If you want to have your business logic on a seperate machine from the presentation layer you would need to wrap that code into a seperate dll and expose it via soap or some other protocol .. and then call those SOAP exposed dlls on the other server from the code in your presentation layer.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
With respect to an application that has both a web and desktop client version:
What is the best practice for the desktop client which needs access to a SQL Server?
What are the benefits of connecting to the database from the application vs using a web service?
Which one provides better security?
What type of scope would call for one vs the other (enterprise intranet vs. web app, etc)
Are there any other considerations that are necessary when choosing on platform?
The general rule of thumb is the following:
Write an independent data access assembly that will talk to the database.
If you are looking for interoperability between different platforms/clients then expose this assembly as a SOAP web service.
If you are looking for performance use the assembly directly in your client .NET applications.
What is the best practice for the desktop client which needs access to a SQL Server?
If you're using a local SQL Server then access the database directly. If the client has to use an SQL database on another system, the use of a web service is preferred for an additional protection and the added advantage of having a business layer that should be able to handle multiple users.
What are the benefits of connecting to the database from the application vs using a web service?
Connecting through a web service will always be a bit slower and modifications to the database will be a bit more difficult to add to the whole system. (Basically, that would mean that you need to create a newer version of the web service while maintaining the older web service for backwards compatibility.)
Which one provides better security?
The use of web services tends to be safer, although security is often more a people issue than software issue. But with the web service between the user and the database, the connection to the database is more secure since the user cannot directly access it. (Except for the functionality you provide through the web service.) This point is moot when client and database are on the same system because then the user can get full access.
What type of scope would call for one vs the other (enterprise intranet vs. web app, etc)
Web services are better for client-server applications, where users should not have direct access to the database. Otherwise, a direct database connection would just improve performance.
When creating a web service, start by writing a generic (class) library which will provide the functionality for the web service. Create a web service around this (business) library, exposing the important methods to the outside world. Any web site could call this library directly without using the web service, although you can always opt to even let the web site code access the data through the web service.
Even if you create just a desktop application with a local database, writing a business library with logic to access the database is just a very good thing to do. Your client could call this business library directly or through a web service, depending on your needs.
Are there any other considerations that are necessary when choosing on platform?
Mostly just the amount of hardware that you're willing to use to set things up. If you can afford to set up a database server, a separate web service for the services and a third for your web site, with a dozen or so client systems, then you can opt for the most layered version, where both client and web site call upon the web service, which calls the database. But if everything needs to run on a single system then just stick to the application and the business layer/library instead.
Adding layers will reduce performance from the view of a single user, though. However, working with multiple layers can improve the overall performance because resources get divided better amongst multiple users.
I'd keep it simple and minimize the amount of layers. Layers cost performance, introduce complexity, and require changes to be made in more locations.
So, if the netwerk connection between the application and Sql Server is open (typically tcp port 1433), I'd use Sql connectivity.
Given the context, there can be a big security concern with client access to databases. It requires either giving users access to the db, or creating a service account. Giving users direct access to the db poses risks. Both approaches open the door to exploiting desktop dll's to connect to db outside of application context (Multiple times I've seen cases where there is a common data access class that all functional operations use. And of course, this components initializes all the connection information. Reflection based access makes it is easy to get to protected or private methods, unless you assert Security Privileges).
Web services expose functional operations that don't expose any sql based operations. Not only is this more secure, it abstracts your client away from your data storage implementation.
Again, it depends on your context. In the Enterprise/ISV realm though, it is generally a big no-no.
If you can acces the DB from the desktop then you should do that.
You have multiple kinds of clients. That means your application should have mulitple layers.
It does not mean you need multiple tiers.
Multiple tiers can be necessary if your layers must transfer data over firewalls or if you have diverse technolgies.
I do a hybrid. Direct database access with limited user who can perform read only from the tables. Webservice with a high privileged database user who can perform write functions. The business rules are built in the webservice (audit trials, permission checks etc)
The direct db access makes it easier for me to develop reports, access lookup values from the client app.