Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
We are working on a medium scale WCF project configured to use per call instancing and wondering weather it's a good practice to create classes per service method to hold the business logic since each service method deals with a single operation and business logic is quite complex ?
Do we need to worry about number of class files in a project considering maintainability (Approximately 100 classes holding service method implementations) ?
Creating a separate class per service method is a bit of overkill, but it absolutely makes sense to have different classes for unrelated methods. So you can have the UserService class to add, update, delete, reset password, or whatever and a FooService to handle all the stuff related to Foo. Ideally you should have a separate class library project where all the classes that hold business logic are kept and a WCF project where all the business methods are called from and the logic to handle the services is kept.
As far as number of files goes, having that many in a project isn't really a problem, they should definitely be separated into multiple folders because its way easier to look at a list of 5-10 folders with 10-20 files than one big list of 100 files.
