I am trying to create few generic activities to select/update/insert records in database.
Is it advisable to do such database operations from WF activities ? Or should I abstract these operations in a WCF service and consume it from the WF ?
Only reason I want to avoid creating a WCF service is that the WF/queries involved are fairly simple. Please advice.
There is no problem doing database queries from your activities. In fact the WF team has create an WF ADO.NET Activity Pack on CodePlex that does just that.
Related
I know there might not be one simple answer for this, but i was hoping if somebody can point me in the right direction...
We have an ASP.NET webforms application with its own MS SQL database at our company's office, but now we want to show some data in this application from another MS SQL database, which is not at our company's office. We need to request the data server-side, so not directly from the webbrowser.
We don't want to use a direct sql connection to this remote database, but prefer to create a service which can do some business logic before returning the data. Business logic is very simple (such as retrieving some values end returning the average).
A couple years ago we did almost the same by writing a WCF service with a BasicHTTPBinding.
But now, after doing a couple hours of research, i'm a little bit confused about whats the best approach?
WCF Service
WCF Data Services
ASP.NET Web API
SignalR
Maybe somebody can give me some good tips?
You're looking for machine-to-machine communications, in which case WCF still beats the rest in my experience.
You simply define data contracts for the entities you wish to exchange and happily code your logic in the WCF service. Then you generate a client, apply the proper binding (given machine-to-machine, net.tcp looks like an efficient candidate) and off they talk.
As for the rest: WCF Data Services - works nice if your data model matches the database model, which hardly ever is the case. When you need custom operations or wish to return different entities than database entities, Data Services are more cumbersome than plain WCF.
ASP.NET Web API and SignalR are mainly meant to consume from a browser. It's harder to generate a strongly-typed client for those.
I am trying to decide which way to go. I have a solution that needs to have a web service and a client side which is a windows phone 7 project. the WP7 project needs to communicate with the database through the WCF service.
I am a little bit confused as to which way i should choose to go, and what are the differences, advantages/disadvantages of regular WCF service file VS the WCF Data Service.
Which way will be easier to go with considering my wp7 app needs to run queries on some tables on the database, nothing too fancy.
Any explanation will be welcomed.
Thanks
WCF Data Services are great if you need CRUD and flexible query capabilities - they allow you to expose underlying data (e.g. via Entity Framework) and control security with a minimum of development effort, as a RESTful API, especially to AJAX and SPA type client front ends. (Also, note that WebAPI now also offers similar capabilities).
WCF Services are more for Formal "Service" and "Operation" integration capabilities, where there is a lot more business focus, e.g. rules, processing, workflow, etc.
e.g. WCF would be useful to Submit a Claim for Processing (custom / rich graph of data input and output), Trigger a Nightly batch job (void response), etc.
Also, you can combine both technologies, e.g. for a CQRS type architecture, by using Data Services for the Query, and WCF for the Command type capabilities.
Our product has two interfaces: a web interface (ASP.NET) and a service interface (WCF).
What is the correct way of connecting them to the business logic? Should the WebUI be just a client for the WCF service (see diagrams below)?
a. WebUI and WCF separated:
User1 -> ASP.NET -/-> Business Layer
User2 -> WCF ----/
b. WebUI is just a client of the service
User1 -> ASP.NET -/-> WCF -> Business Layer
User2 -----------/
If your service exposes absolutely everything that your Web Application needs to do, then why not use it!? ... If this service is going to be given to clients or similar, using it yourself is a great way to test/make sure it does everything you need.
I would encapsulate the Business Logic in a common DLL that both services will use.
In the service(IIS/WCF) handle only communication/protocol/serialization etc ....
This way it's easier to implement and performance is better.
This also depends on the architecture of your client. If you are using something like MVC, you may have the necessity to create large amounts of ViewModels. If your WCF services are granular, it may make sense to make the services return strongly typed DTO objects. If you share the DLL containing the service contracts with your client, you will be able to use the DTOs contained in the service responses as ViewModels. You get the advantage of scaling your UI application and your business logic middle ware differently by decoupling them in this way.
Any experiences with Seam in a one-instance multi-tenant setup? Is Seam suited for that setup? How did you realise it? What were the costs involved?
Our situation: A Seam 2.1 SaaS web-app (POJO, no EJB). Available development budget forced us towards a simplistic one-instance per tenant design. The application is not in production yet but nearly finished.
I expect our customer might reconsider a one-instance multi-tenant setup if it lowers the projected hosting costs.
We've developed a multi-tenant SaaS application with Seam. I don't think that Seam has any advantages or disadvantages for this sort of thing.
The only piece of functionality that is possibly useful are Hibernate Filters (eg. have a company id on every table and set a hibernate filter for it). Means every query will have this ID automatically appended.
I have a class called User, and it has as it's members all of that users data. So, there's a one to many relationship from User to Task, for instance. Then my query for all of a users tasks is simply: select task from Task task, User user where user.id = #{user.id} and task member of user.taskList. I could also have used filters as another has mentioned. However, since the #{user} object is created on log in, it's available via Seams parsing of the EL string. Quite handy.
So, while there is nothing in Seam to support multi-tenant, it's fairly easy to do.
I have a service, business and data access layer. In which layer should I implement transactions using asp.NET transactionscope? Also, is nesting Transactions a good thing because I had problems with that?
Transaction Scope is part of .net not specific to asp.net
We would place the tansaction scope in the business layer. The service layer is more of a facade. If something requires a transaction it should be within a single business operation.