Entities

Entities

• horia14

  I was wondering... have you tried NHibernate to manage the persistence of your entities
  
  

• Vijayanand

  Tim, thanks again the advices.

  About the thin client, I use this terminology for web based UI (opposit rich client for winform UI).

  The requirements of Winform in the presentation is not about offline capabilities but user navegation requirements such as multi windows and other conveniences (sure I could make it with a little ajax or even webforms in .Net 2.0) but today the rich client take a better experience than a thin client (in my oppinion, of course).

  
  

• PriyaKutty

  Tim,

  The system in question will be a customized erp-like (in other words, a big system) to a specific kind of industries where the others classical ERPs don't be much happy.

  The basic requirements here is a database agnostic aproach as I said later and a possibility to remote access (i.e. access to salesman out of the enterprise and even a director in home). Both this is important because some enterprises would use the current DB (the targets here are SQL Server, Oracle and Firebird). The remote access must be flexible and must accept whole functions of the system, so the system running inside and outsite the enterprise should be the same. Additionaly, there's many UI requiriments to use a thin-client presentation so the Winform is the only choice.

  This system will probabily will increase with the time and many customizations will be made here, so a flexible architecture is a good starting point. We are in planning stage and there's many opinions in the design time, but none have a great experience with .Net Framework but just with Java and antecendent technologies.

  We could use a classical OOP-like approach with no problems, but we are finding more about the specific advantages of the .Net Framework and specific resources like the datasets.

  Another question in my mind is using a hardcoded class set for entities like customers and sales request and using a dataset approach for queries like 'the sales from the client x'. It's very reasonably to myself.

  I think this information could help in understand my problem and perhaps help me.

  
  

• Steve Eadie

  Hi Tim and friends.

  I don't make any decision at this time. My expirience in this kind of system is more large in Java and VFP than .Net and I'm looking for some suggestions for more experienced developers.

  The idea of use a dataset-based architecture was take from the Microsoft Pattern website (in a special the Application Architecture for .Net: Designing Applications and Services). However I agree with the problem of couple between layers and it's the main cause of my post.

  Based the Designing Applications and Services the use of datasets is good for fast development and less error-prone code but in the other hands a hardcoded entity set is more flexible and faster in a webservice scenario. This is the theory and I agree with that, but in the real word, with a complicated case like this one (multi-db, webservices in middle tier for remote access) a decision like that is very complicated and I'm not secure of the best .Net approach.

  P.S.: The Entity idea is the Microsoft definition of Entities in a bussines layer (see the Designing Applications and Services for a formal definition).

  
  

• Vojta

  Max,

  It sounds like you have your hands full with this one. Of course what I am going to say is my opinion and others are free to chime in with theirs.

  I am a little confused about one thing. You say you have a requirement that mandates a thin client, but then you say that this means you must you Winforms. Most people refer to Winforms as a thick client. If anything I would think that if your remote users need to work off line that would be justification for using Winforms.

  Now the good thing is that it sounds like you already have a solid OO knowledge base. In this case I probably would lean toward custom business objects (entities).

  You are right that there are best practices in .NET just as there are best practices in Java. But as with anything best practices depend on your situation. You can make your system database agnostic using either datasets or custom classes. The key is actually your data access logic not the container that the data is placed in.

  Personally, if I was doing an application that was doing heavy reporting where filtering the data after it has been retrieved from the database is important I would go with datasets. This is where they are strongest.

  Datasets are pretty flexible. Typed datasets are really no more flexible than custom classes (essentially that is what they are), but they perform better than untyped datasets.

  Datasets carry a lot of extra baggage. If you need performance and scalability and don't have an aversion to writing some base classes to handle some of the things that you might want from datasets like search and sort I would go with custom classes.

  Best of luck.

  
  
  

• Jason David

  Max,

  Sorry if my previous post came off a little to forceful. I was just going off your responses which made it sound like you already have a data access solution which might limit your choices going forward.

  It has been a couple of years since I read the this particular book. You will find there are people on both sides of this argument about datasets vs. custom classes. Personally I usually work on applications that the data comes from multiple databases. That on time of complex manipulation of the data once it is out of the database causes me to lean more toward custom classes and collection.

  If you are doing simple reporting or straight up CRUD opteration you could be ok with datasets. As was stated earlier it does tie you closely to your database. If you change a field name you have to change your UI whereas with custom classes the change would be in your data access mapping.

  Both approaches require care when considering scalability. Datasets have a larger storage footprint if you are using Session. Of course on the other hand, everything in a custom class needs to be serializable and you have to be careful about how you search through collections.

  Ultimately the more information you can give about what your application goals are will allow members here to give better advice.

  
  
  

• Stephan M

  I will second both Clemens and Arnon on this. You are saying entities, but when you start talking about datasets I also think database tight coupling.

  It sounds like you have already made a number of architectural and technical decisions that have locked you on a path. I think you are going to have to either continue down your current path or consider some difficult changes to make your system more flexible and maintainable.

  
  
  

• Amit Basu

  This application use web services to accomplish some requirements as remote access accross firewalls and so on, but this application is not a SOA and will not be used by others applications.

  I agree that if this application should be a SOA implementation, the use of typed datasets is a very bad ideia, but with my requeriments, I think its a real possible. I misunderstand anything in the technology's fundamentals

  I'm looking for a fast development way and a major usability of the .Net framework with less performance problems, but not an optimal solution (what is, I think, a long-time won classes development for entities).

  But I'm opened for ideias. :-)

  
  

• TonyDoherty

  Yes but we looking some thing different in this project.

  
  

• MarkDavies

  I, for one, find it hard to understand what your architecture is - so it is kind of hard to comment if the technology mapping of "entities" into strongly-typed datasets is ok or not.

  Nevertheless, as Clemens pointed out one problem is that you couple everything (all the layers) to the database schema - why do you have layers in the first place

  is this application multi-tiered

  Also you used the term Entities - but basically you just want to move the data around

  
  
  

• PascalLeBeta

  Yes, the DAAB is a nice feature, but I have a custom helper with some specific features that will work fine for me at the moment.

  How do you will develop this kind of application without typed datasets Making a hardcoded class set for entities, using any specific mapper such as NHibernate or another approach

  Thanks for the advices!

  
  

• Jonno232

  If it has to be build fast and there is no need for loose coupeling and al the other benefits of services than I my opion the use of typed datasets is a good idea. Hopefully the erd's are stable

  You should look at the "data access application block" from the patterns and practices group, they already made the helper classes you need.

  
  
  

• tetsu-

  You are using services in the middle tier and you want to use typed datasets to transfer entities between the layers, it's against a rule about services "Services share schema, not class" and you are tightly coupling the layers together. The way to do this is to expose the entities with some crud functionality through services, maybe use some aggregation services and let the presentation layer use them.

  This could be the start of a long discusion

  
  
  
• Entities