I am going to use Entity Framework and WCF in my application. The suggested practice, as I saw, is using POCO with Entity Framework and also using POCO classes as DataContracts. That is actually what POCO and Attributes are used for, -if I am not wrong.
However I am asked to use seperate classses for Entity Framework POCO's and WCF DataContracts. And to use a mapper between POCO's and DataContracts. Like, Foo and FooContract with same properties.
I am on the first approachs side but I wonder if the second approach (seperate classes approach) provides flexibility to the application or is it just a waste of effort.
I will be grateful if you can share your thoughts and experiences about using seperate classes for POCO and DataContracts, pros and cons about that.
Having separate classes for your POCOs and your Contracts will allow you to create Message Oriented services rather than RPC Style services.
Having Message Oriented services will allow your services to be more flexible, do more work, and be less tied to the objects that each service uses.
Message Based services also fall more in line with the spirit of Service Oriented Architectures. You can read more about Message Oriented services at Wikipedia.
I would also suggest picking up Service-Oriented Architecture: Concepts, Technology & Design by Thomas Erl if you are interested in the principles behind good service design.
Having different data classes at persistence layer and contract level gives you the most flexibility. For example, you may not want to expose all your persistent fields over a contract or you may want to expose different hierarchy of data over a contract etc. It also allows to change both independently of each other.
It may seem at first that using different classes at both level is duplication - but over long term, efforts are not so much (compared to flexibility that you get). You may get tempted to use same classes and develop different one when need arises but issue with that approach is that within short time frame, your services get tightly coupled with data classes rather than information/data that services should be exposing/working with.
I agree with #JustinNiessner and the best guidance I have found for architecting .NET applications using SOLID principles is a series of posts by .Net Junkie and the associated codeplex project. Clearly stated and informative, well worth reading.
Related
I am working on a application design and investigating on passing data between WCF services and the ASP.NET web application. Options I am looking at are to either use "Datasets" or Entity Framework.
I have bunch of questions,
If I use Entity Framework to pass data, would it add more overhead to the WCF communication,
Is Datasets considered as "light weight" considering the communication overhead,
If i use Entity Framework, how can I maintain object models if I use stored procedures to return complex data?
Overall I need to figure out pros and cons of using these technologies.
Your question touches on the principles of service-oriented architecture (SOA). In SOA, a service should expose operations (methods) that apply to business objects through contracts. The business objects should be defined in a standard way which is why WCF uses WSDL and XML Schema to do this.
An SOA tenet is that business objects are shared through a schema and/or a contract but not as a specific implementation. By this priniciple, Dataset is a heavyweight, .NET specific, database-oriented object which should not be used to represent a business object. The Microsoft Patterns & Practices group apparently disregards SOA tenets since it shows how to use Dataset as Data Transfer Objects. Whether they're just promoting vendor lock-in or just trashing the whole concept of SOA is anybody's guess. If there is even the remotest chance your service will ever be consumed by a non-.NET client please do not use a Dataset.
If you decide on using the Entity Framework then I'd recommend using Code First to define the Entity Framework data model and just expose those "code first" business objects in your service. This SO question & answers provide a good discussion on using Entity Framework with WCF.
Are you really considering passing entire datasets up and down? This will destroy your object model and be more difficult to maintain, though I suppose you could implement the Repository pattern. Still, even just sending the changes you would need to do strange things like ensure you do not transfer the schema and perhaps using the compress option. But it is a very poor choice when compared to Entity Framework Code First with nice clean POCOs in a separate assembly and without any of the EF infrastructure polluting the DTOs.
EF should not add overhead as such but it depends how it is implemented and what data objects are being passed around. If you pass data into a context and use the correct option when SaveChanges is called such as SaveChangesOptions.ReplaceOnUpdate, only the changed entities will be updated. The queries executed are efficient so long as you are mindful not to lazy load stuff you don't need. You need to understand LINQ to entities well and batch your updates as you would any other potentially expensive method call. Run some tests with your database profiler running and try to improve the efficiency of your interactions with EF, monitor your IIS logs for data sizes and transmission times etc.
Datasets are not considered lightweight due to the need to encapsulate a schema and potentially somebody might make a mistake and send up a whole heap of data in multiple tables, including tables that are dependencies. These might need to be pulled in anyway either on the client or server - very messy! EF does support stored procedures in a sensible manner as they can be part of your model and get called when specific entities need to be saved. ORM will compliment your OO design and lead to cleaner code.
Also if you are doing something simple and only require CRUD without much in the way of business logic consider WCF Data Services.
We are implementing numerous services in our company and running into versioning issues with data contracts. One of the problems we have is that our data contract are also used as the model of the actual application behind the service. I was wondering what approach others have taken in this kind of situation or just service versioning in general. I am aware of the microsoft best practices guide but wanted to see if anybody has any other ideas on how to version.
The first rule of Services, Business Object != Message Object. Basicly, never expose your business objects as data contracts. Or as I like to say, you can't fax a cat. You can send a facsimile of a cat, but you can't send a cat over the wire. Here's a great picture to remind you: http://www.humorhound.com/2009/04/demotivational-poster-youre-doing-it-wrong/
In more modern terms, it is really the MVVM pattern. The view of the model that the domain layer uses is not built for a client, so you have to create a separate model and view for the other layers. Yes it seems like a lot more work, but in the end it is a much easier and better way to build service oriented applications. Versioning is just one of the ways that it makes life easier. The other important thing is that you tend to build models that are geared around how it is going to be used, and you wind up with more explict code (less crazy branching).
The way that we have implemented this is to build a facade layer on top of the business layer.
The facade layer talks to the rest of the world using the objects defined in the data contracts.
The facade layer maps the objects to internal objects before sending the data into the business layer.
This isolates the internal functionality of your system from the objects used in the data contracts.
At my company we are currently using the classic n-tier architecture using NHibernate as our persistence layer with fat objects. Seeing many issues with this pattern, such as full hydration of the object graph when entities are retrieved from the database we have been looking in to other alternatives.
In this process we have moved to a more scalable Command and Query architecture, and now we are looking into the viability of SOA.
In your experiences, what are the biggest advantages of SOA over n-tier. Have you encountered any major hurdles?
And advice and reading material would be helpful.
Besides scalability, SOA offers architectural flexibility. If you decide at some point to move your application from WebForms to Silverlight, both can take equal advantage of a well-designed SOA interface.
You can also decide at some point down the road to offer a new service that takes advantage of some of the features and/or data in your current offering. You just build a new application that is authorized to access your existing interface and away you go.
Loose coupling and governance.
My Team are evaluation to a bigger Business portal. (Invoicing, Bookkeeping, Salaries.....)
We are all used to work with DDD, O/R mappers with NHibernate as our first choice.
We have chosen to work with CompositeWPF to keep modularity between all modules and part system in the business portal.
Now we have evaluated Ria Services and are kind of disappointed how it works in a Data Oriented way, Data Oriented can be good in a service oriented scenario, but we feel that we can with an Object Oriented approach to, and we feel that we can get an application with less complexity with the OO approach than the DO approach.
For example it doesn't allow Value Objects, Many-to-many relations, everything needs to have keys and so on.
We haven't looked at WCF Data Services yet so our question is WCF Data Services our answere? Does it integrate well with Silverlight 4? Can we work with it in a OO manner?
RIA / WCF is not about replacing O/R mappers etc. It is about exposing data in an open format to another application. Not high end, but basically for integration. It is IMHO pretty stupid to put that within an application, but it is a great external interface, especially as it gets tooling support.
Good examples:
Bank accounting access. If I only could do home banking using Odata ;) And get my account statements into excel.
Trading ;) Yeah, ok - I have a trading server (that then connects to various brokers). I have a web front end. I now will expose certain data through OData, too, so I can easily get things out in excel etc., or even use a silverlight application for some stuff... but i will NOT use OData within one application to replace my object infrastructure- way too muc hoverhead.
Ebay could provide an OData interface for larger customers. Nice to get an overview over your auctions AND do some basic maintenance on your account. Nothing high performance, but again, TOOLING support. Excel, Report services all soon support OData.
If you look at it from that integration point of view it makes a LOT mroe sense. It is not a full environment - that "never" works. It is a great standardization, though, to open up an application with semantics (better than web services - standardized query and filter logic) AND tooling support.
I somehow dont really run into many problems with a lot of items you mention, though:
Anything I work with has a key per definition
I neve rdo many:many relations. I always havean interim object WITH A KEY.... so that I can add properties to it (and if that is only a timestamp).
The servies ARE data oriented, and seriously - I love them. I am a big OO fan, but the tooling support makes that a PERFECT external interface for applications.
In my SOA architecture, I have several WCF services.
All of my services need to access the database.
Should I create a specialized WCF service in charge of all the database access ?
Or is it ok if each of my services have their own database access ?
In one version, I have just one Entity layer instanced in one service, and all the other services depend on this service.
In the other one the Entity layer is duplicated in each of my services.
The main drawback of the first version is the coupling induced.
The drawback of the other version is the layer duplication, and maybe SOA bad practice ?
So, what do so think good people of Stack Overflow ?
Just my personal opinion, if you create a service for all database access then multiple services depend on ONE service which sort of defeats the point of SOA (i.e. Services are autonomous), as you have articulated. When you talk of layer duplication, if each service has its own data to deal with, is it really duplication. I realize that you probably have the same means of interacting with your relational databases or back from the OOA days you had a common class library that encapsulated data access for you. This is one of those things I struggle with myself, but I see no problem in each service having its own data layer. In fact, in Michele Bustamante's book (Chapter 1 - Page 8) - she actually depicts this and adds "Services encapsulate business components and data access". If you notice each service has a separate DALC layer. This is a good question.
It sounds as if you have several services but a single database.
If this is correct you do not really have a pure SOA architecture since the services are not independant. (There is nothing wrong with not having a pure SOA architecture, it can often be the correct choice)
Adding an extra WCF layer would just complicate and slow down your solution.
I would recommend that you create a single data access dll which contains all data access and is referenced by each WCF service. That way you do not have any duplication of code. Since you have a single database, any change in the database/datalayer would require a redeployment of all services in any case.
Why not just use a dependency injection framework, and, if they are currently using the same database, then just allow them to share the same code, and if these were in the same project then they would all use the same dll.
That way, later, if you need to put in some code that you don't want the others to share, you can make changes and just create a new DAO layer.
If there is a certain singleton that all will use, then you can just inject that in when you inject in the dao layer.
But, this will require that they use the same DI framework controller.
The real win that SOA brings is that it reduces the number of linkages between applications.
In the past I've worked with organizations who have done it a many different ways. Some data layers are integrated, and some are abstracted.
The way I've seen it most successfully done is when you create generic data-layer services for each app/database and you create the higher level services based on your newly created data layer.